jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23083
Joined: Sat Jul 30, 2011 7:41 pm

Re: RPI 3B+ lies about it's clockspeed. Video

Wed Aug 01, 2018 12:28 pm

Actually this isn;t technically a production error, but variations with chips from a supplier. The production was fine! One could argue that the QC after production should have found the fault, but that actually quite difficult to do. AFAIUI the chip supplier may have changed their binning procedures, but I am not sure.

As for adding docuemntation, I agree it needs to be in there somewhere, it's finding the right place that is difficult.

I also agree that to drop everyone by 15% seems the wrong way round, but actually, its worse for us to have actually failing devices in the field rather than once that could go faster with a slight tweak.

We jsut need to advertise the tweak more!
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

jbudd
Posts: 893
Joined: Mon Dec 16, 2013 10:23 am

Re: RPI 3B+ lies about it's clockspeed. Video

Wed Aug 01, 2018 12:44 pm

How about a post on the blog jamesh? "Openness and life at the bleeding edge".

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23083
Joined: Sat Jul 30, 2011 7:41 pm

Re: RPI 3B+ lies about it's clockspeed. Video

Wed Aug 01, 2018 1:18 pm

jbudd wrote:
Wed Aug 01, 2018 12:44 pm
How about a post on the blog jamesh? "Openness and life at the bleeding edge".
I don't do the blog! I wonder if it might be worth Eben doing a story on the entire thing though. I'll ask.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

hippy
Posts: 5614
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: RPI 3B+ lies about it's clockspeed. Video

Wed Aug 01, 2018 2:03 pm

jamesh wrote:
Wed Aug 01, 2018 12:28 pm
I also agree that to drop everyone by 15% seems the wrong way round, but actually, its worse for us to have actually failing devices in the field rather than once that could go faster with a slight tweak.
That decision makes sense to me. Like over-clocking where that is allowed; the Pi is delivered with a guaranteed stable configuration, then those who wish to venture into potentially unstable territory can choose to do so if they wish.
jamesh wrote:
Wed Aug 01, 2018 12:28 pm
We jsut need to advertise the tweak more!
Agreed. It would also make sense to include an option within raspi-config to configure it, if not there already.

Raspi-config provides an overview of what's available to be changed. For products I get hold of I tend to run through the configuration to see what's there to be changed before seeking further information on what those options mean.
jamesh wrote:
Wed Aug 01, 2018 1:18 pm
I wonder if it might be worth Eben doing a story on the entire thing though. I'll ask.
A FAQ or article on how clocking, throttling, governing, and everything related works, detailing differences across the Pi range, would be very useful.

BadPritt
Posts: 28
Joined: Wed Mar 21, 2018 4:15 pm

Re: RPI 3B+ lies about it's clockspeed. Video

Wed Aug 01, 2018 2:23 pm

jamesh wrote:
Wed Aug 01, 2018 9:06 am
As for video vs text, if you can say it in one paragraph, then you don't need a video! Pretty sure this can be boiled down to
I did add all the information to the first post. So why are you still on that?
I've got a Youtube Channel. So I made a Youtube video about it. I also broke my hand, so typing is a b*tch right now.
I only have got a small youtube-channel. So my reach isn't that big. But it did start the conversation about it. I've also informed people with +100 000 subscribers with this video. If/when they make a video about it, then you would get less friendly comments than mine.

I thank you for giving your insights.
But you must know it is shady that a product suddenly underperforms even agianst it's predecessor. This without informing the users.
I still hope it will be addressed.
I use a fan on my sbc's, so I also didn't notice at first. But most people bought it because it was advertised not to need a fan anymore.

It is also not only Raspbian that shows this behaviour.
Here the results of Ubuntu : http://ix.io/1isM



I've got another question, not really related. (maybe it is, maybe it isn't)
In an earlier video I noticed that the RPi 3B/3B+ are a lot more stable in Ubuntu than in Raspbian. It overclocks higher, performs better, and crashes less. What could be the reason for this?
I used the BMW-Blender benchmark to test the differences. The project takes +1h30m. I know this isn't real proof of high stabillity. But the differences are really big.

Raspbian goes to : 1570 Mhz and dram to 510 Mhz.
Ubuntu goes to : 1585 Mhz and dram to 520 Mhz.

I know you don't like watching my video's, but still here they are.

Overclock in Ubuntu 3B+
https://www.youtube.com/watch?v=tdJrd75_068&t=264s

Overclock in Raspbian on release of the 3B+.
https://www.youtube.com/watch?v=7UbapdFXpqE

Greetings.

NicoD

chwe
Posts: 116
Joined: Tue Jul 31, 2018 1:35 pm

Re: RPI 3B+ lies about it's clockspeed. Video

Wed Aug 01, 2018 2:48 pm

jamesh wrote:
Wed Aug 01, 2018 12:28 pm
Actually this isn;t technically a production error, but variations with chips from a supplier. The production was fine! One could argue that the QC after production should have found the fault, but that actually quite difficult to do. AFAIUI the chip supplier may have changed their binning procedures, but I am not sure.

As for adding docuemntation, I agree it needs to be in there somewhere, it's finding the right place that is difficult.
I don't blame the RPi foundation for things which can happen during the early phase of a new board. Such stuff happens, sometimes it's a fault of the board-design, sometimes a component on the board doesn't perform as it should (as in this case it seems that a batch of the SoCs didn't work as they should). But I think you could do better when you updated the firmware. That's past now and you can't change it anymore but you still can 'spread the word' to enhance the chance that your user-base recognizes it. This would involve:
- Fix your documentation (only vcgencmd measure_clock arm is accurate when it comes to clockspeed)
- Link in your release notes to a blog-post or forum thread or part of the documentation where the new behavior of the firmware is explained described why did you change it and what this means (in terms of reliability and performance). And how the user can revert this change if he decides to do that.

I'm more interested in 'how an organization reacts' when they did something which is IMO wrong than how big the mistake was in the beginning. Weighting how much you did wrong is for the 'shit-storm'-fraction, keep an eye on how you deal with the mistake fits better for me.

TL;TR: I think you did wrong when you decided to lower temp threshold and make it only public in the git history, I think your documentation needs an update towards accurate CPU frequencies (and in the long-term I would 'love' to see a proper fix for it), I think such changes should be shortly described in your release notes and I think it's late but not to late to update those parts on your web-site to make it more visible.
Last but not least, I 'hope' that we both agree up to the point that the current situation isn't satisfactory.

Heater
Posts: 12976
Joined: Tue Jul 17, 2012 3:02 pm

Re: RPI 3B+ lies about it's clockspeed. Video

Wed Aug 01, 2018 3:21 pm

BadPritt,
I've also informed people with +100 000 subscribers with this video. If/when they make a video about it, then you would get less friendly comments than mine.
Meh, who cares? I'm sure the Raspi world is not going to be quaking in its boots because of some twerps unkind comments on his YouTube channel.
Raspbian goes to : 1570 Mhz and dram to 510 Mhz.
Ubuntu goes to : 1585 Mhz and dram to 520 Mhz.
Are you serious?

Those are differences of less than 1% in one case and and 2% in the other.

I doubt whatever you are doing to measure such things is that accurate.

Sounds like a lot if whining over nothing.

Do you complain in the Pizza parlor when your pizza is 1% small than your friends?

BadPritt
Posts: 28
Joined: Wed Mar 21, 2018 4:15 pm

Re: RPI 3B+ lies about it's clockspeed. Video

Wed Aug 01, 2018 3:28 pm

Heater wrote:
Wed Aug 01, 2018 3:21 pm
BadPritt,
I've also informed people with +100 000 subscribers with this video. If/when they make a video about it, then you would get less friendly comments than mine.
Meh, who cares? I'm sure the Raspi world is not going to be quaking in its boots because of some twerps unkind comments on his YouTube channel.
Raspbian goes to : 1570 Mhz and dram to 510 Mhz.
Ubuntu goes to : 1585 Mhz and dram to 520 Mhz.
Are you serious?

Those are differences of less than 1% in one case and and 2% in the other.

I doubt whatever you are doing to measure such things is that accurate.

Sounds like a lot if whining over nothing.

Do you complain in the Pizza parlor when your pizza is 1% small than your friends?
I forgot to mention the Blender results.
Highest overclock in Raspbian 1h55m15s
Highest overclock in Ubuntu 1h40m34s

1% or 2% right????
Last edited by BadPritt on Wed Aug 01, 2018 3:29 pm, edited 1 time in total.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23083
Joined: Sat Jul 30, 2011 7:41 pm

Re: RPI 3B+ lies about it's clockspeed. Video

Wed Aug 01, 2018 3:29 pm

chwe wrote:
Wed Aug 01, 2018 2:48 pm
jamesh wrote:
Wed Aug 01, 2018 12:28 pm
Actually this isn;t technically a production error, but variations with chips from a supplier. The production was fine! One could argue that the QC after production should have found the fault, but that actually quite difficult to do. AFAIUI the chip supplier may have changed their binning procedures, but I am not sure.

As for adding docuemntation, I agree it needs to be in there somewhere, it's finding the right place that is difficult.
I don't blame the RPi foundation for things which can happen during the early phase of a new board. Such stuff happens, sometimes it's a fault of the board-design, sometimes a component on the board doesn't perform as it should (as in this case it seems that a batch of the SoCs didn't work as they should). But I think you could do better when you updated the firmware. That's past now and you can't change it anymore but you still can 'spread the word' to enhance the chance that your user-base recognizes it. This would involve:
- Fix your documentation (only vcgencmd measure_clock arm is accurate when it comes to clockspeed)
- Link in your release notes to a blog-post or forum thread or part of the documentation where the new behavior of the firmware is explained described why did you change it and what this means (in terms of reliability and performance). And how the user can revert this change if he decides to do that.

I'm more interested in 'how an organization reacts' when they did something which is IMO wrong than how big the mistake was in the beginning. Weighting how much you did wrong is for the 'shit-storm'-fraction, keep an eye on how you deal with the mistake fits better for me.

TL;TR: I think you did wrong when you decided to lower temp threshold and make it only public in the git history, I think your documentation needs an update towards accurate CPU frequencies (and in the long-term I would 'love' to see a proper fix for it), I think such changes should be shortly described in your release notes and I think it's late but not to late to update those parts on your web-site to make it more visible.
Last but not least, I 'hope' that we both agree up to the point that the current situation isn't satisfactory.
What you have to consider is what in your humble opinion is wrong may not be others humble opinion.

In this case, very few people knew there even was a soft throttle limit, never mind what the value was. In fact this level is only one change of a number that made the thermal management more reliable (Won't be going in to the other changes so don't ask). The changes all combine to ensure that the heat being 'dumped' through the board and cables doesn't increase too fast or too high, causing a major slow down. ie if the thermal limit is too high (or too close to the max limit) then the procedure to get the temp back down requires a large drop in CPU frequency/ voltage. A lower throttle limit means the CPU frequency changes can be less aggressive, which can actually mean that on average, the lower throttle number gives an overall higher instruction throughput. It's a balancing act. We have to tweak a few parameters to get the best balance, which is what we did. Note that the time taken to heat the board up and cool it back down is very long, on the order of seconds rather than milliseconds, so you also need to take the slow response to changes in to account.

So, this change does not necessarily mean a reduction in overall performance, but if you want to try it out, the config.txt option is there waiting. They would be quite interesting figures to see.

Basically what it comes down to - the 3B+ is faster overall than the 3B, with peak a CPU frequency of 1400Ghz. It's networking is 2-3 times faster, it has much faster wifi, and it's thermal management is much more sophisticated.

And it still costs the same $35. Sometimes I think people forget that.


Note, I will be looking at the docuemtnation to improve the existing overclocking page which covers a lot of stuff https://www.raspberrypi.org/documentati ... locking.md, and maybe add some new sections to make things more obvious, perhaps as part of the technical FAQ change https://github.com/raspberrypi/document ... cal-faq.md
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23083
Joined: Sat Jul 30, 2011 7:41 pm

Re: RPI 3B+ lies about it's clockspeed. Video

Wed Aug 01, 2018 3:31 pm

Heater wrote:
Wed Aug 01, 2018 3:21 pm
BadPritt,
I've also informed people with +100 000 subscribers with this video. If/when they make a video about it, then you would get less friendly comments than mine.
Meh, who cares? I'm sure the Raspi world is not going to be quaking in its boots because of some twerps unkind comments on his YouTube channel.
Raspbian goes to : 1570 Mhz and dram to 510 Mhz.
Ubuntu goes to : 1585 Mhz and dram to 520 Mhz.
Are you serious?

Those are differences of less than 1% in one case and and 2% in the other.

I doubt whatever you are doing to measure such things is that accurate.

Sounds like a lot if whining over nothing.

Do you complain in the Pizza parlor when your pizza is 1% small than your friends?
Just a polite reminder to keep it polite.

If someone want's to YouTube, I'm not stopping them, it's a free world. Mostly. If I consider there are better ways of getting across the information, I'll use them. Simple as.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23083
Joined: Sat Jul 30, 2011 7:41 pm

Re: RPI 3B+ lies about it's clockspeed. Video

Wed Aug 01, 2018 3:40 pm

BadPritt wrote:
Wed Aug 01, 2018 2:23 pm
Raspbian goes to : 1570 Mhz and dram to 510 Mhz.
Ubuntu goes to : 1585 Mhz and dram to 520 Mhz.
This is odd. All the CPU governing etc is done by the GPU not the ARM code (ie linux), so difficult to see why there may be a difference in actually setting the overclocks. It should either work or not, irrelevent of the OS being used. Could be wrong.

The Blender results can also be explained by different versions and build options of software in the different distros. You would need to run exactly the same builds to be sure of valid results.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

BadPritt
Posts: 28
Joined: Wed Mar 21, 2018 4:15 pm

Re: RPI 3B+ lies about it's clockspeed. Video

Wed Aug 01, 2018 4:09 pm

jamesh wrote:
Wed Aug 01, 2018 3:40 pm
The Blender results can also be explained by different versions and build options of software in the different distros. You would need to run exactly the same builds to be sure of valid results.
Indeed, this is a factor.
About a year ago I did the same on the RPi 3b.
There the stock settings result was better in Raspbian. But because Ubuntu was a lot more stable with OC I could get better results in Ubuntu.
But then I used Kdenlive instead, and came to the same conclusion that Ubuntu was more stable with overclocks. Certainly with dram overclock.

Now with Blender the stock settings result was better in Ubuntu. And overclock settings were even 15minutes better.
BadPritt wrote: Highest overclock in Raspbian 1h55m15s
Highest overclock in Ubuntu 1h40m34s
jamesh wrote: And it still costs the same $35. Sometimes I think people forget that.
Many people who have a RPi 3B bought the 3B+ with in mind it was a faster board. Now they are having the same performance with it as with there other 35$ 3B. =+70$...
Also the Rock64 is sold for 25$ with faster ram, USB3, gigabit ethernet, emmc socket, ...

I do believe in Raspberry Pi. And I love the boards. My RPi 2B was a pure delight when I first got it. It still is the better designed board in my eyes.

But time passes by and you're still using the same ram, no real gigabit ethernet, you don't show the real clockspeed in your OS...
Why not be more inovative and lead the way, I've already said you can quickly loose what you have.
Greetings

chwe
Posts: 116
Joined: Tue Jul 31, 2018 1:35 pm

Re: RPI 3B+ lies about it's clockspeed. Video

Wed Aug 01, 2018 5:23 pm

jamesh wrote:
Wed Aug 01, 2018 3:29 pm

What you have to consider is what in your humble opinion is wrong may not be others humble opinion.
Hopefully not! What a boring world when everybody would have the same opinion.... :lol:
IMO your goal should be to find a way which fits best for your user-base. Whereas I can decide if this acceptable for me or not.
jamesh wrote:
Wed Aug 01, 2018 3:29 pm
In this case, very few people knew there even was a soft throttle limit, never mind what the value was. In fact this level is only one change of a number that made the thermal management more reliable (Won't be going in to the other changes so don't ask). The changes all combine to ensure that the heat being 'dumped' through the board and cables doesn't increase too fast or too high, causing a major slow down. ie if the thermal limit is too high (or too close to the max limit) then the procedure to get the temp back down requires a large drop in CPU frequency/ voltage. A lower throttle limit means the CPU frequency changes can be less aggressive, which can actually mean that on average, the lower throttle number gives an overall higher instruction throughput. It's a balancing act. We have to tweak a few parameters to get the best balance, which is what we did. Note that the time taken to heat the board up and cool it back down is very long, on the order of seconds rather than milliseconds, so you also need to take the slow response to changes in to account.

So, this change does not necessarily mean a reduction in overall performance, but if you want to try it out, the config.txt option is there waiting. They would be quite interesting figures to see.

Basically what it comes down to - the 3B+ is faster overall than the 3B, with peak a CPU frequency of 1400Ghz. It's networking is 2-3 times faster, it has much faster wifi, and it's thermal management is much more sophisticated.
Indeed, peak performance =! overall performance. And someone using the boards in a buildfarm with multi hour compilation tasks may have different preferences than someone who let the board idle 99% but has some peak where he needs maximum performance for some seconds. But here, the difference between 'kernel has control' vs. 'blob has control' (over freq. scaling and thermals) come up. On a kernel controlled SBC you send your image with settings you think that they 'should catch' the majority of the use-cases and the experienced users can mess around THS settings in DT (maybe they find better settings for the majority, maybe they find better settings for a special use-case and maybe they just waste a huge amount of time but had fun fiddeling with such settings). On a blob controlled SBC there are only a few variables to play with and when you decide to change the behavior of the blob, the previous optimized settings are worthless and fly around in the wild as 'RPi myths' which you then must explain your user-base again and again that they are not longer true due to changes in the firmware.
I'm impressed how much effort people put into DT tweaks to max out performance or fix RX/TX delays on a GbE capable SBC to increase networkspeed from 8xx mbit/s to 9xx mbit/s. This sort of hardware/software hacker and tinkerers may go for an other SBC.

As said, I like different opinions, the world is big enough for more than one SBC. :lol: IMHO the RPi could do better but it's not up to me to decide what's on your priority list. ;)

Out of curiosity, do you know if the instabilities at 70°C came from thermal issues or due to powering instabilities (e.g. V_cpu isn't stable/high enough to run the board reliable)?

User avatar
DougieLawson
Posts: 35594
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website Twitter

Re: RPI 3B+ lies about it's clockspeed. Video

Wed Aug 01, 2018 5:38 pm

If you measure your Raspberries in "MIPS per square centimetre" you'll be amazed at how powerful your SBC computer is. It's processor power way outstrips the first mainframes (the size of two football fields) I worked on in 1981 (although mainframes always win on I/O throughput because of Gene Amdahl's I/O channel processor).

Niggling about processor speed is pointless. Niggling about RAM, VideoCore, 32-bit and all the other restrictions is pointless. Those things are not going to change any time soon as they have a massive capital cost to change them. Take 64-bit as an example, as soon as Raspbian does that they double the size of the task to keep Raspbian running (as they've got a clearly stated aim to support all the old Raspberry machines). A new VC means a massive manufacturing cost. More RAM needs a new VC with the same costs.

I'm fairly sure the very clever folks at Raspberry Towers in Cambridge have a well defined plan for where they go next with the RPi4 or whatever emerges as the next £35 small board computer. Until it hatches from it's cocoon we have to sit back and appreciate what they've given us (and the 20 million other folks) with their re-purposed mobile phone technology and Linus Torvald's free operating system.
Note: Having anything humorous in your signature is completely banned on this forum. Wear a tin-foil hat and you'll get a ban.

Any DMs sent on Twitter will be answered next month.

This is a doctor free zone.

gkreidl
Posts: 6001
Joined: Thu Jan 26, 2012 1:07 pm
Location: Germany

Re: RPI 3B+ lies about it's clockspeed. Video

Wed Aug 01, 2018 5:59 pm

DougieLawson wrote:
Wed Aug 01, 2018 5:38 pm
If you measure your Raspberries in "MIPS per square centimetre" you'll be amazed at how powerful your SBC computer is. It's processor power way outstrips the first mainframes (the size of two football fields) I worked on in 1981 (although mainframes always win on I/O throughput because of Gene Amdahl's I/O channel processor).

Niggling about processor speed is pointless. Niggling about RAM, VideoCore, 32-bit and all the other restrictions is pointless. Those things are not going to change any time soon as they have a massive capital cost to change them. Take 64-bit as an example, as soon as Raspbian does that they double the size of the task to keep Raspbian running (as they've got a clearly stated aim to support all the old Raspberry machines). A new VC means a massive manufacturing cost. More RAM needs a new VC with the same costs.

I'm fairly sure the very clever folks at Raspberry Towers in Cambridge have a well defined plan for where they go next with the RPi4 or whatever emerges as the next £35 small board computer. Until it hatches from it's cocoon we have to sit back and appreciate what they've given us (and the 20 million other folks) with their re-purposed mobile phone technology and Linus Torvald's free operating system.
There are always a lot of people who know better - but none of them can do better :-)
Minimal Kiosk Browser (kweb)
Slim, fast webkit browser with support for audio+video+playlists+youtube+pdf+download
Optional fullscreen kiosk mode and command interface for embedded applications
Includes omxplayerGUI, an X front end for omxplayer

BadPritt
Posts: 28
Joined: Wed Mar 21, 2018 4:15 pm

Re: RPI 3B+ lies about it's clockspeed. Video

Wed Aug 01, 2018 6:53 pm

gkreidl wrote: There are always a lot of people who know better - but none of them can do better :-)
Have you tried any other SBC's? Odroid's are a pleasure to work with. The community is amazing and a lot friendlier than the RPi community.
The C2 is way better than any RPi.
It's fast (1.75Ghz), it's got a lot more/better ram, everything just works on it. I use my C2 as a laptop. I could not do that with the RPi 3B since overheats way to quickly, and no good voltage regulation to work with powerbanks.
Ok it cost a bit more, and doesn't have wifi. But it's way better and a lot older than the 3B/3B+.
Then again the Rock64 has got USB3, gigabit ethernet, eMMC module socket, ... And the 1GB version is sold for 25$.

I've got many different SBC's. Some are good design but crappy support. Some crappy design and better support(Asus)
Raspberry Pi 3B crappy design, RPi 3B+ a lot better design but outdated as hell.

So many can do better. But they don't have the community that RPi has.
And that 35$ gag. You can buy the NanoPi Fire3-LTS octa-core 1gb ddr3 SBC for 35$, Rock64 2GB ddr3 35$, ........
And many other are cheaper. As if 35$ is giving it away.

Again. If you sell a board with certain claims and benchmarks and so on. And you change the characteristics of the board. And then it even gets disguised by the OS. That is something that could shrink that awesome big community. I only want the best for RPi.
I expect things like this from Apple. But an Apple isn't a Raspberry is it?
I do believe that there was a problem, and don't find it bad they underclock at 60°C.
But if they don't communicate about it, and leave the people to be clueless. Then that's a strange thing in that great Raspberry Pi Foundation team.

I have said enough about it.
Greetings

wildfire
Posts: 507
Joined: Sat Sep 03, 2016 10:39 am
Location: Dundee, Scotland

Re: RPI 3B+ lies about it's clockspeed. Video

Wed Aug 01, 2018 7:08 pm

BadPritt wrote:
Wed Aug 01, 2018 6:53 pm
I have said enough about it.
OK, I've read enough. If you favour other SBC's for their capabilities and or price that's your choice and you're welcome to it, but don't diss the RPI community. Apart from a few trolls (which coincidentally have few posts) I find most posters here very helpfull.
NF

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23083
Joined: Sat Jul 30, 2011 7:41 pm

Re: RPI 3B+ lies about it's clockspeed. Video

Wed Aug 01, 2018 7:27 pm

Rather than quote I'll just put thoughts in one post.

It's a thermal issue. Voltage stability on the 3B+ is greatly improved.

Because of the underlying chip architecture, the GPU HAS to control the ARMs, AIUI that cannot be changed.

The next Pi will be called the Pi4. Yes, it's well defined and fully intends to fix ALL the issues that have come up in this thread.

If you think other boards are so much better, why are you posting so much on here?

Rockchip Devices, I beleive, are subsidised by the SoC manufacturer. Raspbery Pi continues to fund education with the profits from sales.

The tweaks to the thermal parameters probably means an increase in overall perormance. Peak speed is still 1400Mhz. Not sure why people think there is such an issue here. We have sacrificed a small amount of perfomance to ensure stability acros the gamut of SoC skews, but to most that will be imperceptible, but the headline numbers are still correct. The 3B+ runs faster and is more stable than the 3B.

Speed of innovation. We like to spend time of time to make sure it works. Developing a SBC takes a long time, especically if you have to ensure that it adheres to all the compliance regualtions worldwide. Which we do, unlike many others. The move from Pi3 to Pi4 is a big jump, as many know we have pretty much reached the limits of the SoC on its current process., which makes development even longer, especially when you consider the SoC requirements. We are in effect at the mercy of third parties. We also try VERY hard to remain backwards compatible, which is vital for our primary task, but is also a rod for our backs with regard to innovation. If we stopped being backwards compatible we could have all sorts of devices out there with enormous specs, but would we be at the same level of success as ODroid, or Rockwell devices.....?

The Pi4 is going to be awesome. I know this.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

Heater
Posts: 12976
Joined: Tue Jul 17, 2012 3:02 pm

Re: RPI 3B+ lies about it's clockspeed. Video

Wed Aug 01, 2018 7:28 pm

Indeed, horses for courses. If some other device fits ones needs better then no one is saying one should not use it.

The Odroid C2 for example looks great. It would cost me about three times as much to get one here after accounting for delivery and import duties. I don't need any more horsepower than the Pi delivers so I can't justify splashing out for C2 instead of Pi.

Isn't it great how the arrival of the Pi inspired others to provide dirt cheap Linux SBCs? Before that such things were a lot more expensive and not generally available to or useable by Joe Public.

chwe
Posts: 116
Joined: Tue Jul 31, 2018 1:35 pm

Re: RPI 3B+ lies about it's clockspeed. Video

Wed Aug 01, 2018 7:41 pm

DougieLawson wrote:
Wed Aug 01, 2018 5:38 pm
If you measure your Raspberries in "MIPS per square centimetre" you'll be amazed at how powerful your SBC computer is. It's processor power way outstrips the first mainframes (the size of two football fields) I worked on in 1981 (although mainframes always win on I/O throughput because of Gene Amdahl's I/O channel processor).
Pointless, I don't care when the whole surface of my SBC is SoC or not (as long as thermals are okay :lol: ). With 'some tolerance' every recent SoC will be in the same MIPS/cm² range than the Pi (some a bit higher some a bit lower). Everything else is like trying to compare apples and pears.
DougieLawson wrote:
Wed Aug 01, 2018 5:38 pm
Niggling about processor speed is pointless. Niggling about RAM, VideoCore, 32-bit and all the other restrictions is pointless. Those things are not going to change any time soon as they have a massive capital cost to change them. Take 64-bit as an example, as soon as Raspbian does that they double the size of the task to keep Raspbian running (as they've got a clearly stated aim to support all the old Raspberry machines). A new VC means a massive manufacturing cost. More RAM needs a new VC with the same costs.
Niggling about those small chunks can sum up and then have a impact which might matter.. Not for everyone but for some people. The fact that this stuff happens 'under the hood' might be a reason why people interested in this stuff chose other boards.
gkreidl wrote:
Wed Aug 01, 2018 5:59 pm
There are always a lot of people who know better - but none of them can do better :-)
Exactly this kind of argumentation makes such a discussion 'pointless'... I don't argue that the RPi is crap and that everyone using a RPi must be brainwashed cause *random SBC* outperforms every RPi on *random use-case* by a factor of *random number*. Overall, the RPi does well, some other boards too. There are use-cases where the RPi performs better on the other side, there are use-cases where others do better. The off-topic part about maxing out performance etc. was just to show why I think that kernel controlled hardware is better than blob controlled others are free to disagree on that.
My main point is how an organization deals with such changes which have (or can have) an impact on the boards behavior and I think that @jamesh agrees here that the gitlog alone was probably not sufficient..

ejolson
Posts: 3260
Joined: Tue Mar 18, 2014 11:47 am

Re: RPI 3B+ lies about it's clockspeed. Video

Wed Aug 01, 2018 8:27 pm

jamesh wrote:
Wed Aug 01, 2018 3:40 pm
The Blender results can also be explained by different versions and build options of software in the different distros. You would need to run exactly the same builds to be sure of valid results.
Raspbian binaries are compiled to be reverse compatible with ARMv6, which makes them slower than binaries targeting the ARMv7 instruction set. The performance reduction in Blender seems minor compared to what happens with some libraries for numerical computation.

ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5790
Joined: Fri Jul 29, 2011 5:36 pm
Location: The unfashionable end of the western spiral arm of the Galaxy

Re: RPI 3B+ lies about it's clockspeed. Video

Wed Aug 01, 2018 8:43 pm

ejolson wrote:
Wed Aug 01, 2018 8:27 pm
jamesh wrote:
Wed Aug 01, 2018 3:40 pm
The Blender results can also be explained by different versions and build options of software in the different distros. You would need to run exactly the same builds to be sure of valid results.
Raspbian binaries are compiled to be reverse compatible with ARMv6, which makes them slower than binaries targeting the ARMv7 instruction set. The performance reduction in Blender seems minor compared to what happens with some libraries for numerical computation.
Which ones? Most of the popular ones have runtime detection to use NEON when it's available, where most of the performance improvement comes from. In some cases, two versions of the .so are shipped - one armv6 and one armv7. Then ld.so loads the correct one depending ont he CPU. If there are commonly used libraries which are not optimised, that's something that could be fixed.

AFAIK, the various BLAS libraries tend to be popular for this and seem to already use NEON.

wh7qq
Posts: 1301
Joined: Thu Oct 09, 2014 2:50 am

Re: RPI 3B+ lies about it's clockspeed. Video

Thu Aug 02, 2018 1:44 am

I've read the entire 2 pages of this thread and maybe I missed it but nobody seems to call a spade a spade and point out the rashness of the title. The use of the term "lies" implying, deliberately or not, that RPF is indulging in false advertising...all based on a single sample. It would be quite enough to point out the issue and describe it as fully as one can without an accusation of chicanery on the part of a non-profit foundation or even attributing the problem to all 3B+ examples when the test sample is so small..

RPis are not perfect but I have an Intel built Atom Mobo that with its flakey bios and unsupported graphics is nearly trash and it is widely known to be so. Plenty of complaints out there in the wild. I might find it useful in a headless mode but as a desktop it is a failure. Intel never fessed up to what a POS it was. I am sure that AMD has similar turkeys out there. When you build complex devices, perfection is not always attainable. The 7 RPis I have: three zeros, two B+s, a 2 and a 3B all have their limitations and imperfections. You either work with it or find another solution.

For a long time, I used the 3B in preference to the Atom...at least I could get 1920x1080 out of it. The biggest limitation on the 3B and the 3B+, to me, is the pathetic little memory on board. One Meg just does not cut it with modern browsers, even with all sorts of ad and script blockers and a pi-hole up front in a separate Rpi. The 3B doesn't just slow down when hot...it 'effin quits. Same as you approach the high end of memory usage. Wrong tool for the job. Arctic silver epoxy and copper sinks cured the heat problem but no way to fix the memory. I don't think anyone has lied to me as the fitness of the 3B for my demands was never claimed.

I hope this thread has run its course and the Mods choose to close it up.

Tzarls
Posts: 224
Joined: Tue Feb 26, 2013 6:59 am

Re: RPI 3B+ lies about it's clockspeed. Video

Thu Aug 02, 2018 5:30 am

wh7qq wrote:
Thu Aug 02, 2018 1:44 am
One Meg just does not cut it with modern browsers, even with all sorts of ad and script blockers and a pi-hole up front in a separate Rpi. The 3B doesn't just slow down when hot...it 'effin quits.
You mean 1 Gig, right?

FWIW, I have a RPi3B in an AIY Voice V1 - no heatsink, locked in a cardboard box with stock AIY image. Installed VLC (without hardware acceleration) and tried watching HD videos just because. Temperature went to 81, 82 and stayed there... Closed VLC and everything continued working as if nothing happened.

jahboater
Posts: 4595
Joined: Wed Feb 04, 2015 6:38 pm

Re: RPI 3B+ lies about it's clockspeed. Video

Thu Aug 02, 2018 5:38 am

Yes, the thread title should be altered.
wh7qq wrote:
Thu Aug 02, 2018 1:44 am
The 7 RPis I have: three zeros, two B+s, a 2 and a 3B all have their limitations and imperfections. You either work with it or find another solution.

The 3B doesn't just slow down when hot...it 'effin quits.
You haven't tried the new 3B+ ! Thermal management is one of its headline features.
It retains good performance when hot, I have never succeeded in getting it to throttle back below 1GHz even after sustained stress tests in hot weather. With a decent heat sink, mine will not throttle back at all with normal (non-stress test) workloads, so I get 1.4GHz all the time - which I am very happy with. Web browsing doesn't even get it warm ...

Return to “General discussion”