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

RPI 3B+ reports incorrect clockspeed. Video

Mon Jul 30, 2018 4:35 pm

Hi all. I've made a new video where I found out that the RPi 3B+ lies about it's clockspeed.

https://www.youtube.com/watch?v=dDWv0A36W9s

All the needed information: (added later for more convenience)

Without a fan, the RPi-3B+ runs at 1.2Ghz with the newest release of Raspbian and when the temperature exceeds 60°C.
On the first release (March 13th 2018) this happend when it reached 70°C.

A fix for this is to add "temp_soft_limit=70" in config.txt

Another thing I show is that a "bad" 2.5A PSU is a lot worse than a good 2A PSU. Check the Non RPi PSU scores for this.

Here are my benchmark results.

Raspbian Stretch June 27 2018 results
---------------------------------------------------------------
RPi 3B+ No OC No fan RPi PSU http://ix.io/1iGM
RPi 3B+ OC 1570 No Fan Rasp PSU http://ix.io/1iGz

RPi 3B+ No OC With Fan+heatsink RPi PSU http://ix.io/1iHr
RPi 3B+ OC 1570 With fan/heatsink RPi PSU http://ix.io/1iHA

RPi 3B No OC No fan with heatsink RPi PSU http://ix.io/1iHI
RPi 3B No OC With fan/heatsink RPi PSU http://ix.io/1iHV

Raspbian Stretch 2018-03-13
------------------------------------------------
RPi 3B+ No OC No Fan http://ix.io/1iI5


Non RPi PSU's
------------------------
RPi 3B+ No OC No fan Crappy 2.5A PSU Undervoltage when maxed out in 7zip http://ix.io/1iH0
RPi 3B+ No OC No fan 2A PSU (not a bad one) http://ix.io/1iHb



Here the explanation from TKaiser. He can put it all a lot better into words than I can. He's a lot more knowledgeable than me.

Quoted from TKaiser
"Benchmarking the Raspberry Pi is useless when not taking into account that there always is a primary operating system running on the primary CPU (VideoCore) that fully controls the hardware. ARM cores are just guests here. That's why sbc-bench starting with v0.2 also logs ThreadX version and configuration (/boot/config.txt)
Looking at RPi 2 B+ numbers this is 2 times the same hardware, one time running latest Raspbian Stretch Lite and one time OMV/Armbian. Userland is both times Debian Stretch but Raspbian packages are built for ARMv6 while upstream Debian builds for ARMv7 (though with less effective compiler switches). Overall performance looks more or less the same except a very low memcopy bandwidth value with OMV. What's the reason since same ditro and kernel is used and same GCC to compile tinymembench? Is it firmware 'af8084725947aa2c7314172068f79dad9be1c8b4 from Apr 16 2018' vs. '47b05c853342eb6e4ea5b017d981e0ef247fb8be from Jul 3 2018'?
Looking at RPi 3 B+ numbers it's obvious that 'firmware' version is the most important factor. With original firmware (6e08617e7767b09ef97b3d6cee8b75eba6d7ee0b from Mar 13 2018) performance is ok just to get trashed after applying firmware 4800f08a139d6ca1c5ecbee345ea6682e2160881 from Jun 7 2018 which totally changes throttling behaviour. From then on you either need a fan for good performance or add a temp_soft_limit= entry to the firmware config file (we can't have a look what all those partially undocumented settings really do since RPi's main operating system is closed source)"
End Quote.
https://github.com/ThomasKaiser/sbc-ben ... Results.md

Link to SBC-Bench by TKaiser.
https://github.com/ThomasKaiser/sbc-bench



Greetings.
Last edited by BadPritt on Tue Jul 31, 2018 8:09 pm, edited 5 times in total.

DirkS
Posts: 9872
Joined: Tue Jun 19, 2012 9:46 pm
Location: Essex, UK

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

Mon Jul 30, 2018 4:45 pm

Sorry, can't watch that video for more than 30 seconds while you're stumbling through that 'performance'
Why not just write it down instead of making it a painful experience for everyone...
Last edited by DirkS on Mon Jul 30, 2018 5:10 pm, edited 1 time in total.

echmain
Posts: 224
Joined: Fri Mar 04, 2016 8:26 pm

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

Mon Jul 30, 2018 4:55 pm

So it’s *faster* than we thought? Sweet!

ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5764
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

Mon Jul 30, 2018 5:00 pm

I've managed to make it through most of the video.

For the people who couldn't, the short non-clickbaity version is that the kernel doesn't accurately report the clock rate.

The recommended way of getting an accurate clock rate is 'vcgencmd measure_clock arm'.

AIUI, the behaviour comes from a problem in the upstream driver which is responsible for reporting the clock rate, but I can't find a reference right now. Dom or Phil would be best to comment, since they're know exactly what the issue is.

In any case, it's not, as the video seems to imply, an insedious plot to mislead anybody. If you want to measure the clock rate accurately, the recommended way has always been through vcgencmd.

DirkS
Posts: 9872
Joined: Tue Jun 19, 2012 9:46 pm
Location: Essex, UK

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

Mon Jul 30, 2018 5:10 pm

Cheers @Shift+1

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

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

Mon Jul 30, 2018 5:57 pm

ShiftPlusOne wrote:
Mon Jul 30, 2018 5:00 pm
I've managed to make it through most of the video.

For the people who couldn't, the short non-clickbaity version is that the kernel doesn't accurately report the clock rate.

The recommended way of getting an accurate clock rate is 'vcgencmd measure_clock arm'.

AIUI, the behaviour comes from a problem in the upstream driver which is responsible for reporting the clock rate, but I can't find a reference right now. Dom or Phil would be best to comment, since they're know exactly what the issue is.

In any case, it's not, as the video seems to imply, an insedious plot to mislead anybody. If you want to measure the clock rate accurately, the recommended way has always been through vcgencmd.
Thank you for your responce. I know my English isn't very good. But it's the information that's important.
I do not imply it's a plot. I just point out that this has changed in the new release of Raspbian. It is just a fact that when you are not using a fan, it doesn't work at the same speed as when it was released. I find this important information.

I hope Dom or Phil can comment on this.

Cheers, have a nice day.
NicoD

ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5764
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

Mon Jul 30, 2018 6:21 pm

BadPritt wrote:
Mon Jul 30, 2018 5:57 pm
ShiftPlusOne wrote:
Mon Jul 30, 2018 5:00 pm
I've managed to make it through most of the video.

For the people who couldn't, the short non-clickbaity version is that the kernel doesn't accurately report the clock rate.

The recommended way of getting an accurate clock rate is 'vcgencmd measure_clock arm'.

AIUI, the behaviour comes from a problem in the upstream driver which is responsible for reporting the clock rate, but I can't find a reference right now. Dom or Phil would be best to comment, since they're know exactly what the issue is.

In any case, it's not, as the video seems to imply, an insedious plot to mislead anybody. If you want to measure the clock rate accurately, the recommended way has always been through vcgencmd.
Thank you for your responce. I know my English isn't very good. But it's the information that's important.
I do not imply it's a plot. I just point out that this has changed in the new release of Raspbian. It is just a fact that when you are not using a fan, it doesn't work at the same speed as when it was released. I find this important information.

I hope Dom or Phil can comment on this.

Cheers, have a nice day.
NicoD
Your English is fine. Certianly better than that of many native speakers. And sorry for assuming bad intentions.

There's already a thread about this, I just can't find it. The reason that the temperature at which the clock drops down to 1.2GHz changes to 60C was, as you've correctly stated at the end of the video, was due to stability issues on a small percentage of 3B+'s

Why wasn't this change communicated clearly? I don't know. The changelog for the images is written by Simon, who works on the UI, not the firmware. I make minor changes to the changelog and would've mentioned the change in behaviour, but I only found out after it was reported on the forum.

In short, the cpufreq driver doesn't report the clock rate accurately, but the only change on our end was that the frequency drops to 1.2GHz above 60C. The changelog of the images reflects changes made to the desktop and the image building proccess. The changelog for the kernel and the firmware is seperate and in the form of git commit messages.

This particular change seems to be mentioned here: https://github.com/raspberrypi/firmware ... dbcb75088d

ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5764
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

Mon Jul 30, 2018 6:26 pm


DirkS
Posts: 9872
Joined: Tue Jun 19, 2012 9:46 pm
Location: Essex, UK

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

Mon Jul 30, 2018 6:45 pm

And as mentioned in these posts you can get the old behaviour back by using 'temp_soft_limit=70' in config.txt

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

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

Mon Jul 30, 2018 6:50 pm

Thank you. I had not found that thread.
I now have added subtitles, I hope it's a little less horrible to watch with that.
Greetings.

DirkS
Posts: 9872
Joined: Tue Jun 19, 2012 9:46 pm
Location: Essex, UK

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

Mon Jul 30, 2018 7:05 pm

BadPritt wrote:
Mon Jul 30, 2018 6:50 pm
I now have added subtitles, I hope it's a little less horrible to watch with that.
Well, AFAIC the biggest problem is that the subject matter is not really suitable for video.
If it's written down it's much easier to skip forward / back and reread, etc.

ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5764
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

Mon Jul 30, 2018 7:14 pm

For me the issue wasn't the language either. It was just that's it's a 9 minute video that could have been summed up in a short paragraph. The only visually relevant parts of the video were text, which could have been pasted or linked to. Video just doesn't seem like the right kind of format for that content.

If you were keeping the content to youtube, maybe that would appeal to some, but it doesn't cross over well to a forum. Maybe the thing to do would've been to explain the issue in text and then plug the youtube video for people who are interested.

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

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

Mon Jul 30, 2018 7:33 pm

The reason that the temperature at which the clock drops down to 1.2GHz changes to 60C was, as you've correctly stated at the end of the video, was due to stability issues on a small percentage of 3B+'s

Why wasn't this change communicated clearly? I don't know. The changelog for the images is written by Simon, who works on the UI, not the firmware. I make minor changes to the changelog and would've mentioned the change in behaviour, but I only found out after it was reported on the forum.

In short, the cpufreq driver doesn't report the clock rate accurately, but the only change on our end was that the frequency drops to 1.2GHz above 60C. The changelog of the images reflects changes made to the desktop and the image building proccess. The changelog for the kernel and the firmware is seperate and in the form of git commit messages.
Thank you for your insights on this.
DirkS wrote:
Mon Jul 30, 2018 7:05 pm
BadPritt wrote:
Mon Jul 30, 2018 6:50 pm
I now have added subtitles, I hope it's a little less horrible to watch with that.
Well, AFAIC the biggest problem is that the subject matter is not really suitable for video.
If it's written down it's much easier to skip forward / back and reread, etc.
Indeed.
Here are my benchmark results.

Raspbian Stretch June 27 2018 results
---------------------------------------------------------------
RPi 3B+ No OC No fan RPi PSU http://ix.io/1iGM
RPi 3B+ OC 1570 No Fan Rasp PSU http://ix.io/1iGz

RPi 3B+ No OC With Fan+heatsink RPi PSU http://ix.io/1iHr
RPi 3B+ OC 1570 With fan/heatsink RPi PSU http://ix.io/1iHA

RPi 3B No OC No fan with heatsink RPi PSU http://ix.io/1iHI
RPi 3B No OC With fan/heatsink RPi PSU http://ix.io/1iHV

Raspbian Stretch 2018-03-13
------------------------------------------------
RPi 3B+ No OC No Fan http://ix.io/1iI5


Non RPi PSU's
------------------------
RPi 3B+ No OC No fan Crappy 2.5A PSU Undervoltage when maxed out in 7zip http://ix.io/1iH0
RPi 3B+ No OC No fan 2A PSU (not a bad one) http://ix.io/1iHb


Without a fan, the RPi-3B+ runs at 1.2Ghz with the newest release of Raspbian and when the temperature exceeds 60°C.
On the first release (March 13th 2018) this happend when it reached 70°C.

A fix for this is to add "temp_soft_limit=70" in confix.txt

Another thing I show is that a "bad" 2.5A PSU is a lot worse than a good 2A PSU. Check the Non RPi PSU scores for this.

Here the explanation from TKaiser. He can put it all a lot better into words than I can. He's a lot more knowledgeable than me.

Quoted from TKaiser
"Benchmarking the Raspberry Pi is useless when not taking into account that there always is a primary operating system running on the primary CPU (VideoCore) that fully controls the hardware. ARM cores are just guests here. That's why sbc-bench starting with v0.2 also logs ThreadX version and configuration (/boot/config.txt)
Looking at RPi 2 B+ numbers this is 2 times the same hardware, one time running latest Raspbian Stretch Lite and one time OMV/Armbian. Userland is both times Debian Stretch but Raspbian packages are built for ARMv6 while upstream Debian builds for ARMv7 (though with less effective compiler switches). Overall performance looks more or less the same except a very low memcopy bandwidth value with OMV. What's the reason since same ditro and kernel is used and same GCC to compile tinymembench? Is it firmware 'af8084725947aa2c7314172068f79dad9be1c8b4 from Apr 16 2018' vs. '47b05c853342eb6e4ea5b017d981e0ef247fb8be from Jul 3 2018'?
Looking at RPi 3 B+ numbers it's obvious that 'firmware' version is the most important factor. With original firmware (6e08617e7767b09ef97b3d6cee8b75eba6d7ee0b from Mar 13 2018) performance is ok just to get trashed after applying firmware 4800f08a139d6ca1c5ecbee345ea6682e2160881 from Jun 7 2018 which totally changes throttling behaviour. From then on you either need a fan for good performance or add a temp_soft_limit= entry to the firmware config file (we can't have a look what all those partially undocumented settings really do since RPi's main operating system is closed source)"
End Quote. https://github.com/ThomasKaiser/sbc-ben ... Results.md

Link to SBC-Bench by TKaiser.
https://github.com/ThomasKaiser/sbc-bench

fanoush
Posts: 459
Joined: Mon Feb 27, 2012 2:37 pm

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

Tue Jul 31, 2018 11:38 am

ShiftPlusOne wrote:
Mon Jul 30, 2018 7:14 pm
It was just that's it's a 9 minute video that could have been summed up in a short paragraph.
It is generation thing. Reading and writing is hard :-) And I'd say it works in a way. youtube is full of video tutorials that may feel laughable to you but if current kids would need to read or write that information to share it, it would not be done at all. I see it on my kids. Yes, it takes longer to watch it but somehow it is more useful to them than just reading web page or piece of paper.

ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5764
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

Tue Jul 31, 2018 11:46 am

fanoush wrote:
Tue Jul 31, 2018 11:38 am
ShiftPlusOne wrote:
Mon Jul 30, 2018 7:14 pm
It was just that's it's a 9 minute video that could have been summed up in a short paragraph.
It is generation thing. Reading and writing is hard :-) And I'd say it works in a way. youtube is full of video tutorials that may feel laughable to you but if current kids would need to read or write that information to share it, it would not be done at all. I see it on my kids. Yes, it takes longer to watch it but somehow it is more useful to them than just reading web page or piece of paper.
I'm very guilty of this myself. When I had trouble understanding sections of textbooks or certain lectures at uni, I could sometimes find clearer explanations on youtube from the likes of EEVBlog, GreatScott, Pete from SparkFun and so on.

For some things I still find that approach useful. For example, when getting into 3D printing, watching videos helped fill some gaps in knowledge, which would've been harder to do in text. There is some value in being shown something rather than reading about it, but it depends on the context.

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

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

Tue Jul 31, 2018 3:28 pm

AIUI, the behaviour comes from a problem in the upstream driver which is responsible for reporting the clock rate, but I can't find a reference right now. Dom or Phil would be best to comment, since they're know exactly what the issue is.
so it's an upstream issue when 'more or less' every other SBC can properly report it's clock-speed to the kernel expect the RPi? IMO it's an issue of your firmware which is known since years and didn't get a proper fix. You have a workaround for it, but it is what it is.. It's a workaround not a fix.
The changelog for the kernel and the firmware is seperate and in the form of git commit messages.
you advertise the RPi as a board for beginners right? Beginners might not be familiar with the concept of getting the information on various sources. Then you should write a tutorial where I get the informations. Something like: Userspace changes can be found here (link to your changelog), kernel and firmware changes can be found in our repo. If I look into the release notes:
* Bluetooth updates
- Firmware with Bluetooth 4.2 features
- SCO profile suppot added via bthelper.service
* Linux kernel 4.14.50+
* Raspberry Pi firmware 748fb17992426bb29d99224b93cb962fefbdc833
you've sub-notes for what you've changed in your bluetooth stuff. Why not for the kernel and the firmware? If it's mostly applying greg's LTS patches for the kernel, well there's no need for a special announcement. But at least for the firmware something like: "Lower temperature thresholds to 60°C" would be nice to see.
If you were keeping the content to youtube, maybe that would appeal to some, but it doesn't cross over well to a forum. Maybe the thing to do would've been to explain the issue in text and then plug the youtube video for people who are interested.
Why not the other way around (as he did)? Getting some attention on youtube and link to forums where the whole stuff is discussed in detail. @BadPritt it may make sense to link this thread to in your video description. Indeed the video isn't perfect e.g. he could make some graphs out the results to make it easier to compare results but that's time vs. being fast enough. As long as making youtube clips isn't your full-time job you might not have perfect videos everytime. As long as he links to sources where you get more informations, it's IMO accurate and a responsible way of generating content.

Discussing if this is the right way of spreading this informations to a broader community is IMO less worth my time than see a video on youtube... As the moderators here stated multiple times, this forum is part of the RPi foundation. I understand everyone who wants to spread his findings and opinions on a platform independent from the foundation.
Well, AFAIC the biggest problem is that the subject matter is not really suitable for video.
If it's written down it's much easier to skip forward / back and reread, etc.
Why not? cause you have to read something shown on a video? :D Well the video was uploaded in FullHD so you can read it when you want, and the topic affects the whole userbase with a behavior which wasn't there when all the benchmark videos/reports where made for the new RPi 3B+. That's exactly the content I would like to see from all those benchmark generators.. That they monitor the benchmarked products over time to find such changes. Normally it should go better over time but it's more important when performance decreases.
There's already a thread about this, I just can't find it. The reason that the temperature at which the clock drops down to 1.2GHz changes to 60C was, as you've correctly stated at the end of the video, was due to stability issues on a small percentage of 3B+'s
To be honest? That sounds fishy.. If it only affects a small amount of boards you should either refund them (cause you delivered a board which shouldn't pass your QC), or point them to a workaround (e.g. if you run into instabilities you can adjust the thermals to "temp_soft_limit=60" in config.txt). And if that small percentage is not as small as you want us to believe, then you should be honest and clarify what went wrong and why you think it's appropriate to lower the thermal thresholds for everyone. Increased clock-speed and better thermals was one third of the 'bullet points' when you annotated the new board in your blog-post (https://www.raspberrypi.org/blog/raspbe ... le-now-35/). If you take then into account that 'GbE over USB2' only works reliable when your router on the other side of the wire allows flow-control.. There's not much left where the average RPi user can benefit from.

Don't get me wrong, an update of your board is appreciated (especially 5GHz wifi was a smart decision) but three out of six major updates on the 3B+ don't work as promised/expected and that should be taken into account. Maybe your boss can write a follow up blog post where he explain those issues in more detail? When even the RPi engineers can't find the forum thread related to this issue anymore..
There's already a thread about this, I just can't find it.
Is it appropriate communication to expect that the average user finds this information? A forum with:

Code: Select all

Total posts 1283858 • Total topics 188835 • Total members 239020
might not be the right place to address those issues...

p.s. seems that I'm not smart enough to quote here properly.. If someone has a hint how to do this, I'm glad to learn it. :)

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

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

Tue Jul 31, 2018 7:51 pm

chwe wrote: p.s. seems that I'm not smart enough to quote here properly.. If someone has a hint how to do this, I'm glad to learn it. :)
Under the reply window you see the whole forum thread. Go to the part you want, select it, and press the quote button at the upper right of the post. Better do it so they know about it.
Thank you for your support. I hope to hear a comment back from anyone Raspberry related.

I
ShiftPlusOne wrote: In short, the cpufreq driver doesn't report the clock rate accurately, but the only change on our end was that the frequency drops to 1.2GHz above 60C. The changelog of the images reflects changes made to the desktop and the image building proccess. The changelog for the kernel and the firmware is seperate and in the form of git commit messages.
Will this problem be addressed?
For me it's not so bad that it underclocks. If there's an easy fix like this, no problem. But the users must be able to see real clockspeeds in there OS.

I also think the Rasp 3B+ is a better product than the 3B. If it isn't massively overheating like the RPi-3B, it's got faster WIfi. Good points.
But compared to other SBC's it lags behind. Only big advantage is the big community.
You can lose that quickly if you don't treat them good.
Friendly greetings. Thank you

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

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

Wed Aug 01, 2018 9:06 am

I'm not sure how easy it is to fix, not my area. We try and make sure that as much of the Pi specific code get upstreamed - this makes maintenance much easier, and means easy access to the source for everyone. However, getting stuff accepted can be nightmarish, and can take a lot of time even for apparently simple change.

There is clearly an accurate and well documented alternative to the Linux standard CPU frequency stuff, so for the moment this is low priority, given the possible amount of work required, and we are pretty busy.


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

"Due to using upstream code for CPU frequency reporting, that does not take in to account the control the GPU has over the ARM core frquency, the standard linux reporting for the CPU frequency can give erroneous results. Please use vcgencmd measure_clock arm to get an accurate number. With regard to CPU speed throttle control on the 3B+, the clock speed is reduced from 1400Mhz to 1200Mhz at the temp_soft_limit. This defaults to 60, can be raised to a maximum of 70 in config.txt, but this may cause instability on a minority of 3B+ devices."

See here https://www.raspberrypi.org/documentati ... locking.md

That documentation is a bit difficult to find though, I'll have a think about how to make it more obvious.
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."

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

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

Wed Aug 01, 2018 9:21 am

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

"Due to using upstream code for CPU frequency reporting, that does not take in to account the control the GPU has over the ARM core frquency, the standard linux reporting for the CPU frequency can give erroneous results. Please use vcgencmd measure_clock arm to get an accurate number. With regard to CPU speed throttle control on the 3B+, the clock speed is reduced from 1400Mhz to 1200Mhz at the temp_soft_limit. This defaults to 60, can be raised to a maximum of 70 in config.txt, but this may cause instability on a minority of 3B+ devices."
...
+1
This takes a few seconds to read and understand. The youtube video will take longer to start ...
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

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

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

Wed Aug 01, 2018 9:42 am

I think it's pretty neat (cool?) that the Pi slows itself down when it's not busy and if it gets too hot. I'm pleased that it minimises both my electricity bill and the risk of fires.

However, the Pi 3B+ is presented as wringing the maximum performance from the hardware so it does seem odd to quietly reduce performance of everyone's board.

Do you have any data about what proportion of Pi 3B+ are affected? "A minority" might be 1%, it might be 49%

Perhaps you could publish a script to test and verify if a particular Pi is affected?

Edit - If a Pi is affected, you could offer to refund the difference in price between the 3B+ and the 3B :D

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

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

Wed Aug 01, 2018 10:05 am

jbudd wrote:
Wed Aug 01, 2018 9:42 am
I think it's pretty neat (cool?) that the Pi slows itself down when it's not busy and if it gets too hot. I'm pleased that it minimises both my electricity bill and the risk of fires.

However, the Pi 3B+ is presented as wringing the maximum performance from the hardware so it does seem odd to quietly reduce performance of everyone's board.

Do you have any data about what proportion of Pi 3B+ are affected? "A minority" might be 1%, it might be 49%

Perhaps you could publish a script to test and verify if a particular Pi is affected?

Edit - If a Pi is affected, you could offer to refund the difference in price between the 3B+ and the 3B :D
Not sure of the percentage, much less than 1% though, of the original production run. It was a few in the original batch AFAIK. We had some sent back here for testing and replaced them. I would expect every one sold now to be able to run at a temp_soft_limit of 70, but I suppose it always possible we get a test escape.
It's a bit of a pain really. None of the test devices showed the problem, it was only, AIUI, a particular batch from the fab that didnt like the slightly higher temperature. But I got that info second hand, so might be slightly wrong in exact details.

Not sure a script would be able to detect the issue. It exhibited as a random lock up of the device, which is not really suseptible to accurate detection.
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: 876
Joined: Mon Dec 16, 2013 10:23 am

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

Wed Aug 01, 2018 10:25 am

Hmm. It didn't arise with your pre-release boards and there isn't an easy way to test.
So it's only a guess what proportion are susceptible..
Probably a sensible decision to reduce temp_soft_limit then!

No criticism of the Pi Foundation, it's an excellent product!

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

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

Wed Aug 01, 2018 10:58 am

jbudd wrote:
Wed Aug 01, 2018 10:25 am
Hmm. It didn't arise with your pre-release boards and there isn't an easy way to test.
So it's only a guess what proportion are susceptible..
Probably a sensible decision to reduce temp_soft_limit then!

No criticism of the Pi Foundation, it's an excellent product!
An educated guess, from the number of issues reported vs the number of boads sold, and from internal testing of boards i.e. we did not have ANY production or prototype boards that showed the fault, and had to ask people who had problem boards to send them in for testing. So a very low percentage indeed and AFAIK current production boards are NOT susceptible, so that percentage decreases every day.
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."

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

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

Wed Aug 01, 2018 11:38 am

This sort of problem must be impossible to detect during production and very hard afterwards given its rarity.
A defective supplied chip is bad luck, not really the RPF's fault.

The only problem I had was that I had to raise an issue on github before the 60C workaround came to light - given that for nearly all users it is a unneeded slow down.

What are the effects of the 60C throttling limit? This seem to range from a post by @rpdom where his 3B+ was over 60C at idle (in an enclosed box, no heatsink) - not sure what happens then, to my board which is in free air with a large heat sink where 60C is almost never reached. During the recent heatwave in the UK GCC released a new version, so I built it (all four cores active for over 4 hours) and monitored the temps. With an ambient (room temperature) of 30C, the Pi temp briefly peaked at 60.7C.
jbudd wrote:
Wed Aug 01, 2018 10:25 am
No criticism of the Pi Foundation, it's an excellent product!
+1
The 3B+ is the best Pi model ever IMHO :)

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

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

Wed Aug 01, 2018 12:18 pm

jamesh wrote:
Wed Aug 01, 2018 9:06 am
I'm not sure how easy it is to fix, not my area. We try and make sure that as much of the Pi specific code get upstreamed - this makes maintenance much easier, and means easy access to the source for everyone. However, getting stuff accepted can be nightmarish, and can take a lot of time even for apparently simple change.

There is clearly an accurate and well documented alternative to the Linux standard CPU frequency stuff, so for the moment this is low priority, given the possible amount of work required, and we are pretty busy.


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

"Due to using upstream code for CPU frequency reporting, that does not take in to account the control the GPU has over the ARM core frquency, the standard linux reporting for the CPU frequency can give erroneous results. Please use vcgencmd measure_clock arm to get an accurate number. With regard to CPU speed throttle control on the 3B+, the clock speed is reduced from 1400Mhz to 1200Mhz at the temp_soft_limit. This defaults to 60, can be raised to a maximum of 70 in config.txt, but this may cause instability on a minority of 3B+ devices."

See here https://www.raspberrypi.org/documentati ... locking.md

That documentation is a bit difficult to find though, I'll have a think about how to make it more obvious.
But even when I find then the 'difficult to find' documentation (IMO not, it's help-->documentation as for more or less every other project which comes with documentation):
In that To view the Pi's current frequency, type: cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq. Divide the result by 1000 to find the value in MHz.
To be a bit heretical, "it's well documented, how to do it wrong". But fact is, that most devs rely on the 'standard linux way' how to collect those informations. E.g. the RPi monitor (https://github.com/XavierBerger/RPi-Mon ... u.conf#L11) gets its CPU info where it isn't correct. IMO here you need to be more clear in your documentation so that people who develops programs for the Pi have the chance to do it right. Those issues are known since months (years?) but still wrong in your documentation. Keeping the documentation up-to-date is hard and a lot of work but devs and end-users rely on this information and your faults will be found in third party developed 'apps'. Getting them to fix their code is harder, the longer it rests faulty in your documentation. An other fix would be that you change the behavior of cpu freq driver in your kernelfork so that everyone who relies on your kernel gets at least accurate cpu frequencies.
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

"Due to using upstream code for CPU frequency reporting, that does not take in to account the control the GPU has over the ARM core frquency, the standard linux reporting for the CPU frequency can give erroneous results. Please use vcgencmd measure_clock arm to get an accurate number. With regard to CPU speed throttle control on the 3B+, the clock speed is reduced from 1400Mhz to 1200Mhz at the temp_soft_limit. This defaults to 60, can be raised to a maximum of 70 in config.txt, but this may cause instability on a minority of 3B+ devices."
Means that we will see this 'boiled down' paragraph soon in the official RPi documentation? :)
jamesh wrote:
Wed Aug 01, 2018 10:58 am
jbudd wrote:
Wed Aug 01, 2018 10:25 am
Hmm. It didn't arise with your pre-release boards and there isn't an easy way to test.
So it's only a guess what proportion are susceptible..
Probably a sensible decision to reduce temp_soft_limit then!

No criticism of the Pi Foundation, it's an excellent product!
An educated guess, from the number of issues reported vs the number of boads sold, and from internal testing of boards i.e. we did not have ANY production or prototype boards that showed the fault, and had to ask people who had problem boards to send them in for testing. So a very low percentage indeed and AFAIK current production boards are NOT susceptible, so that percentage decreases every day.
Out of curiosity, is it worth to lower the CPU frequency by 15% for every user (seems that 60°C is reached quite fast when there's some load on the CPU) when you think that only <1% is affected by this issue? I would prefer the other way around but that's up to you do decide if you prefer to deal with the people which complain that their Pi is slower since the last update or the people which complain that their board doesn't run stable.
jbudd wrote:
Wed Aug 01, 2018 9:42 am
I think it's pretty neat (cool?) that the Pi slows itself down when it's not busy and if it gets too hot. I'm pleased that it minimises both my electricity bill and the risk of fires.
It's not about throttling when the board is idle, it's about throttling when the board is under high load which affects now every benchmark you can find 'in the wild' cause they were made with a different behavior of the firmware. From my SBC experience, there are more efficient ways to minimize your electricity bill, e.g. buy a PSU which runs efficient, shutdown everything you don't need for example GbE when fast ethernet is suitable, HDMI and GPU related stuff when it runs headless. Throttling is something which 'more or less' every arm SoC with a mature upstream support does.
An other 'trick' to save energy: Chose the device which is 'just powerful enough' for the job you want to achieve, for example if you monitor 10 temperatures on various places in and around your house it will be a way more power efficient to have 10 ESP32 with a thermoprobe sending it's data to an RPi than 10 RPis (if you don't care much about 'fancy graphics' and elaborate data processing the master could be an ESP32 too).. :P But we're going off-topic here. ;)
jbudd wrote:
Wed Aug 01, 2018 9:42 am
Edit - If a Pi is affected, you could offer to refund the difference in price between the 3B+ and the 3B :D
smart... Other opinion, you refund them the 3B+ cause you delivered them a board which shouldn't pass QC. I don't blame the RPi foundation for production errors which can happen when you come up with a new board. Shouldn't but can happen. But try to 'nail down' which batch(es) are affected, figure out what went wrong to ensure it doesn't happen in your future production batches and refund/replace the boards which are affected (an 'educated price-calculation' should allow to replace <1% of the boards in case something like this happens, if you can nail down it to one batch a recall should be possible).

Return to “General discussion”