RPi 3B+ Heat/CPU related improvements.

[tkaiser]

As a note to the forum moderators who usually censor here everything they don't understand: https://archive.fo/3itQt -- it's archived.

You can do what you usually do (censoring) but it gets press coverage this time

[ejolson]

with faked cpufreq values reported by the kernel on RPi.

Why so upset? I think most Pi users interested in monitoring CPU frequency (including you) know to use vcgencmd. It appears the kernel reports the desired frequency based on load, but the actual frequency based on heat and power management may be less.

Things can always be better documented; however, from my point of view the Raspberry Pi team is direct, transparent and doesn't try to hide details about how the system actually works.

[gkreidl]

... So as expected the 1.2GHz DVFS OPP with RPi 3 B+ shows a lower voltage compared to the RPi 3 and it's still the same shit show with faked cpufreq values reported by the kernel on RPi. If you don't query ThreadX running on the main CPU (VC4) you have no idea what's happening.

Anyway, it's useless to discuss anything here. This forum and the whole RPi micro reality suffers from censorship. I expect my posting getting deleted by one of those retarded RPi censors soon.

For posts like this you will get banned on most forums. Critical comments are one thing, bad behavior is something else.

BTW, it has been clearly stated by the Foundation, that the clock speed will be reduced to 1200 MHz, if temperature reaches 70 degrees and that further throttling will start at 80.

[tkaiser]

I think most Pi users interested in monitoring CPU frequency (including you) know to use vcgencmd.

Unfortunately this is not the case. Users expect

Code: Select all

/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

being correct but the number exposed there does not reflect reality both in throttling and more importantly in frequency capping situations (when your RPi runs under-volted and cpufreq will be limited to 600 MHz).

All Linux monitoring solutions use scaling_cur_freq since this sysfs value by design should show the correct CPU clockspeeds. Only exceptions I know of: Raspberry Pi and Amlogic TV boxes and SBC (there also a proprietary firmware hides what's happening in reality).

[jamesh]

Wow - the full GCC build on the Pi3+ took 4.6 hours! down from 5.3 hours for the Pi3.

I ran your stat program at the same time as cpuburn53 :-

Code: Select all

Time       Temp  CPU fake/real     Health state    Vcore
...
19:46:27: 70.4'C 1400/1200 MHz 0000000000000000000 1.2438V

Thank you. So as expected the 1.2GHz DVFS OPP with RPi 3 B+ shows a lower voltage compared to the RPi 3 and it's still the same show with faked cpufreq values reported by the kernel on RPi. If you don't query ThreadX running on the main CPU (VC4) you have no idea what's happening.

Anyway, it's useless to discuss anything here. This forum and the whole RPi micro reality suffers from censorship. I expect my posting getting deleted by one of those retarded RPi censors soon.

What on earth is your problem? You turn up, start slagging the Pi off, start having a go at other forum users, use bad language, have had multiple reports made against your posts (many of them not particularly charitable, but they keep it to private reports)

And you are the one getting antsy?

Moderators really don't need the sort of hassle your presence is causing, I've banned you for a week, if you want to come back, please moderate your behaviour or accept that the mods will do it for you.


As for the 'faked' cpufreq values, what on earth are you taking about (rhetorical question given you banned status). We don't fake anything. There might be bugs in the reporting though.

[tkaiser]

As for the 'faked' cpufreq values, what on earth are you taking about (rhetorical question given you banned status). We don't fake anything. There might be bugs in the reporting though.

Ok, then consider this being a bug report then. Linux standard to report the current CPU clockspeed is

Code: Select all

/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

On Raspberry Pi this value is bogus since not reporting the CPU clockspeed but just some fantasy value in those situations where either throttling occurs or frequency capping. Please fix this and make scaling_cur_freq reporting the real clock speeds.

Of course afterwards the forum will be flooded by users reporting their Pis only running at 600 MHz all the time as result of insufficient powering

[jamesh]

Bug reports should go in the kernel GitHub, or you can provide fixes as a pull request on the same GitHub.

As for censorship, hardly anything gets deleted or changed on this forum, and very few people get banned. No idea where you get this censorship idea from.

In some ways, as someone who has had posts deleted and has been banned, you are in an elite and select group. I think congratulations are in order.

[Gareth Halfacree]

https://medium.com/@ghalfacree/benchmar ... 122cf3d806

That's an interesting comparison of Pi computers, especially the heat dissipation analysis. The Linpack Mflop numbers are surprisingly low. A Pi 3B when configured correctly gets more than 6000 double-precision Mflops when running at 1200MHz, but the graph shows about 200 Mflops, which is a factor of 30 times too slow. When running benchmarks, it is important to compare new with previously established results.

Hi there! I'm the guy wot did the benchmarks, and I completely agree that it's important to compare like-for-like - which is why I carried out the full testing across all Pi models on the same day using the same software revision on the same operating system release (in fact, on the same micro-SD card - literally taking it out of one Pi and putting it into the next in line.) Comparing my results to results obtained using different versions of different software running on a different operating system release is ill-advised - even where the software has the same name.

If you want to try the exact same version of Linpack I was using, you'll find it on Roy Longbottom's page. Using the double-precision Armv7 binary from there on an unmodified Pi 3 (non-Plus) gets 178.18 MFLOP/s. Whether Roy's version is comparable to A. N. Other version of Linpack doesn't affect the results in any way: the benchmarks are there as a comparative between Pi models, and using the same benchmark on each Pi means that it serves the purpose well.

(It's also the same benchmark I used for the launch of the Pi 3, Pi 2, and Pi Zero - which, if you felt like digging out old copies of The MagPi, means you can also see how changes in the operating system itself have affected performance over time!)

Same with Gigabit Ethernet numbers but my favourite is the Wi-Fi 'Benchmark'. Neither bandwidth nor latency are benchmarked but 'signal quality' (and labeling channels as cells, claiming RPi 3 wouldn't be able to use channels 9 to 13 and that 3 B+ being able to use those would be related to 5GHz is plain weird).
Funny 'benchmarking gone wrong' example

First: the gigabit Ethernet result is wholly accurate; it is bottlenecked by sharing a single USB 2.0 lane to the SoC. Try it yourself!

Second: you appear to have completely the wrong end of the stick on the Wi-Fi benchmark. It does not graph channels, it graphs - as is very clearly marked on the graph - cells, which is the terminology used by iwlist to refer to base stations. In other words, a Pi 3 is used to scan for and rate the signal quality of any wireless network base stations (access points, routers, or mobile hot spots) it can see in the surrounding area using "iwlist scanning"; a Pi 3B+ is then used to scan for and rate the signal quality of any wireless network base stations it can see. These are numbered by iwlist as "Cell 1", "Cell 2", "Cell 3", and so on. The results are then sorted by BSSID (because Cell 1 on the first scan might be Cell 5 on the second scan, and you'd be comparing apples to oranges) and charted.

The Pi 3B+ is the only one that can see Cells 9-13, because those cells - not channels - operate in the 5GHz spectrum. Quite why you thought I was graphing channels, or what you thought "signal quality" on a given channel would mean in that context, I have no idea - other than that you saw that there were 13 cells (a coincidental number, which could have been higher or lower if I'd done the test elsewhere) and thought "there are 13 channels in 2.4GHz Wi-Fi, that's what he must have meant."

Well, it wasn't. Happy to clear that up for you!

Anybody else have any questions?

[bensimmo]

Wow - the full GCC build on the Pi3+ took 4.6 hours! down from 5.3 hours for the Pi3.

I ran your stat program at the same time as cpuburn53 :-

Code: Select all

Time       Temp  CPU fake/real     Health state    Vcore
...
19:46:27: 70.4'C 1400/1200 MHz 0000000000000000000 1.2438V

Thank you. So as expected the 1.2GHz DVFS OPP with RPi 3 B+ shows a lower voltage compared to the RPi 3 and it's still the same shit show with faked cpufreq values reported by the kernel on RPi. If you don't query ThreadX running on the main CPU (VC4) you have no idea what's happening.

Anyway, it's useless to discuss anything here. This forum and the whole RPi micro reality suffers from censorship. I expect my posting getting deleted by one of those retarded RPi censors soon.

With the last comment certainly.
Some people here may have medically 'retarded' members in the family. Certainly doesn't go down well in the UK.

[Heater]

tkaiser,

This forum and the whole RPi micro reality suffers from censorship. I expect my posting getting deleted by one of those retarded RPi censors soon.

Can't help but chuckle at that.

It's like someone getting invited to a party, they are not even expected to bring a bottle, everyone is having a great time. Then someone starts complaining that the food is terrible, the wine is cheap, slagging of the host and all the other party goers.

Then they wonder why they get bounced out of the party...all the while complaining how badly wronged they are...

[jamesh]

tkaiser,

This forum and the whole RPi micro reality suffers from censorship. I expect my posting getting deleted by one of those retarded RPi censors soon.

Can't help but chuckle at that.

It's like someone getting invited to a party, they are not even expected to bring a bottle, everyone is having a great time. Then someone starts complaining that the food is terrible, the wine is cheap, slagging of the host and all the other party goers.

Then they wonder why they get bounced out of the party...all the while complaining how badly wronged they are...

I tend to get rid of party people like that....ooooh, what a coincidence. I am awaiting an influx of complaints about how nasty we all are, how we are limiting freedom of speech (there isn't any one here by the way), how they are so upset I kept deleting their posts referencing (with pictures) Orange Pi's, how they should be allowed to point out how crap the new Pi is on the Pi forums (Duh, er, no). I've already had one cockwomble on the blog stating I need psychiatric help, so I'm pretty much prepared.

Also, note how we've left the posts above in place, because we are SO harsh with our censorship...

[ejolson]

Comparing my results to results obtained using different versions of different software running on a different operating system release is ill-advised - even where the software has the same name.

Agreed. Since about 1993 the Linpack benchmark has referred, not to running a particular code, but to solving a particular problem (systems of linear equations) using a particular mathematical algorithm (Gaussian or LU factorisation with partial pivoting). The rules are that the problem size should be large enough that it doesn't fit entirely in the cache of a single processor and that you can't use an algorithm which has different asymptotic time complexity, like Strassen's method, to solve the problem. The fact that Linpack refers to solving a particular problem rather than running a particular code has allowed Linpack to be a useful measure of computing performance for 25 years.

Roy Longbottom's Linpack code is historically interesting and running it on modern hardware a fascinating act of retro computing. However, publishing the speed of that code as Linpack benchmark results out of context is confusing and makes the Pi hardware look 30 times slower than it really is.

[Gareth Halfacree]

Roy Longbottom's Linpack code is historically interesting and running it on modern hardware a fascinating act of retro computing. However, publishing the speed of that code as Linpack benchmark results out of context is confusing and makes the Pi hardware look 30 times slower than it really is.

I can certainly understand your perspective, but again: the benchmark set is designed purely as a comparative of the performance of each Raspberry Pi model against each other Raspberry Pi model, and is presented as such; as all models are running the exact same benchmark, that comparison remains both intact and useful (and historically comparable against the benchmarks I published at the launch of other Pi models, handily demonstrating improvements made through OS and firmware optimisations, which would not be the case if I now switched to a different Linpack implementation which gives an order-of-magnitude different result.)

Here's the thing: if I removed the X-axis labelling from the graph, so it was just bare bars with no numbers at all, the comparison would still be valid - and the graph would look identical, I would expect, to a Linpack implementation which runs 30 times faster on the same hardware.

[ejolson]

Here's the thing: if I removed the X-axis labelling from the graph, so it was just bare bars with no numbers at all, the comparison would still be valid - and the graph would look identical, I would expect, to a Linpack implementation which runs 30 times faster on the same hardware.

That is an interesting expectation, but not what I'd expect. The only way to know for sure is to actually do the work to find out. Except for the 3B+ I can fill in most of that comparison. I'll do so in a few days. Maybe someone else will have results for the 3B+ by then.

[Gareth Halfacree]

That is an interesting expectation, but not what I'd expect.

Interesting - what would make you not expect that, if the benchmark you're using is a stable 30-times-faster than Roy's implementation?

Let me know if you carry out testing across the Pi range. I'd be interested in seeing the results. Sadly, I'm off onto the next project now - and won't be pulling the old Pis out of mothballs again until the next major hardware release!

[rhildinger]

I've already had one cockwomble on the blog stating I need psychiatric help, so I'm pretty much prepared.

"Cockwomble" is now my favorite word. I shall be overusing it with impunity to annoy my coworkers...

[Heater]

jamesh,

Hmm..I presume the "cockwomble" is the male of the womble species. As opposed to the female "henwomble"?

To be honest I could never tell the difference without turning them upside down.

Are we even allowed to make such gender differentiation in polite company now a days ?

All I remember is that I'm supposed to remember I'm a womble:
https://www.youtube.com/watch?v=VIxkqoNi8I4

[davidcoton]

I spent six years at a school right on the edge of Wimbledon Common. I hope that doesn't make me a cockwomble.

[ejolson]

with faked cpufreq values reported by the kernel on RPi.

I think most Pi users interested in monitoring CPU frequency (including you) know to use vcgencmd.

You are right, there are also some who don't know. In this case, they were paying attention and figured it out.

[PeterO]

All I remember is that I'm supposed to remember I'm a womble:
https://www.youtube.com/watch?v=VIxkqoNi8I4

Also don't forget that "exercise is good for you laziness is not"
PeterO

[killwater]

If anyone is interested in how the pi looks without the metal spreader this guy removed it:
https://www.youtube.com/watch?v=4LtL9e7JqxE

Looks like the heat transfer area is actually quite small.

[Hir0]

Hello everybody,

I have just joined this community. Since I have got the chance to have both models 3b and 3b+, I have made some temperature measurements and compared the results:

Ambient temperature 28 °C

Raspberry Pi 3b (without case):
In idle the temperature ranges between 46.2 and 48.3 °C
Under load:
temp=48.3'C, frequency(45)=600062000, throttled=0x0, volt=1.2000V
temp=76.3'C, frequency(45)=1200000000, throttled=0x0, volt=1.3188V
temp=80.6'C, frequency(45)=1141000000, throttled=0x20002, volt=1.3188V
temp=82.2'C, frequency(45)=1034000000, throttled=0x20002, volt=1.3188V
temp=82.2'C, frequency(45)=1034000000, throttled=0x20002, volt=1.3188V
Tmax=82.2'C

By probing directly the heat sink, I get 43 °C (idle) and 74 °C (load) for the cpu and 43 °C (idle) and 50 °C (load) for ethernet controller.

Raspberry Pi 3b+ (without case):
In idle the temperature ranges between 52.6 and 54.2 °C
Under load:
temp=53.7'C, frequency(45)=600064000, throttled=0x0, volt=1.2000V
temp=68.8'C, frequency(45)=1200000000, throttled=0x0, volt=1.2500V
temp=72.5'C, frequency(45)=1200000000, throttled=0x0, volt=1.2500V
temp=75.2'C, frequency(45)=1200000000, throttled=0x0, volt=1.2500V
temp=76.8'C, frequency(45)=1200000000, throttled=0x0, volt=1.2500V
Tmax=78.4'C

Here the probe on the heat sink shows 48 °C (idle) and 71 °C (load) for the cpu and 55 °C (idle) and 62 °C (load) for ethernet controller.

The heat is better distributed over the board but the ethernet/usb controller as well as the usb ports they get quite hot. Unfortunately I did not check what temperature level the two boards reached before applying the heat sinks.
The Raspberry Pi Foundation did a very good job with the model 3B+ although I do not like the fact that the heat spreader over the CPU is not flat and reduce the contact surface with the heat sink.
Although many people are contrary to mount a fan on the raspberry pi, personally I would find very usefull to have 4 holes around the cpu to hold a fan. As soon as I put the pi 3b+ into the case, it gets hot quickly with cpu temperature in idle around 66°C.

Does anybody have an idea why the CPU does not run at 1.4Ghz? It does not get throttled.

[bertlea]

I guess your script just skipped the data when the CPU temperature is under 60 degree. Your first temperature/CPU speed logged seems not a valid one as the speed is just 0.6GHz which is the CPU seems not yet running with heavy loading. You can try to start your script when the CPU is cool to give it a chance to log the CPU under-loading but not yet reach 60 degree.

* I assume you are using the latest version of Raspbian that it now starts throttling the CPU at lower temperature at 60 degree instead of 70 degree previously.

[Hir0]

Thanks for your reply! I thought the threshold value was at 70°C. Another user here was posting the command to bring this value up to 70°C but I have edit slightly my post and his/her comment has disappeared.

According to you, are normal the temperature levels of the USB/Ethernet controller in the model 3B+?

[bertlea]

Your CPU temperature is very similar to what I got when I compared my 3B and 3B+, and jamesh from this forum responded to my findings as:

The 3B+ SoC simply runs hotter - it's a higher clock speed, the board has the faster and hotter ethernet chip on it, and the wifi chip can also get hot...

.

I never measured the USB/Ethernet controller, so I do not know if your readings are normal or not.