RPi 3B+ Heat/CPU related improvements.

[killwater]

Hello.
From the blog post I assume that the CPU speed boost is only the effect of better thermal management. This raises a few questions:
1. How does the heat spreader work? Is it only a metal plate put on top of the chip casing or is there a better thermal connection with the cores themselves? Will the heat transfer to heatsink installed on top be significantly better?
2. Is the additional power draw going to cook any PI in a case? This heat has to go somewhere...
3. Has anyone managed to run long duration CPU benchmarks with temp monitoring for 3B and 3B+ for comparison? Would be extremely useful.

Best regards

[rpiMike]

Some info here, including thermal images:

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

[Imperf3kt]

Some info here, including thermal images:

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

Hmm, an improvement I overlooked.

Perhaps there is merit to me buying a Pi3b+
Thanks for the detailed link.
(I'm not the OP, just someone who held similar questions)

I wonder if it's worth lapping that SoC package xD

[rpiMike]

I got a Pi3B+ today - it does run a lot cooler when pushed hard.

Old Pi3 with large aluminium heatsink used to touch 80 degrees running Minecraft - had to add a fan.

Pi3B+ runs Minecraft just over 60 degrees with no heatsink and no fan.

[tweak42]

Some info here, including thermal images:

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

Ah very informative thermal images.
Now I'm curious if there is any overclocking overhead left with the new power system and heatspreader. Eben had stated when the Pi 3 shipped that it was about the max mhz of the current architecture die size, so the B+ 200mhz bump is surprising.

[mahjongg]

the main trick is that they have flipped the chip (SoC) upside down, the back of the chip is completely flat and can make excellent thermal contact with the heat spreader that is mounted directly to it, the heat spreader in turn is thermally attached to the ground plane of the PI, so that heat is transferred to all corners of the PI. This much better thermal arrangement makes that the chip isn't such a hot spot as it was before.
you can see how efficient this works in the thermal pictures linked to in the previous post.

[rpiMike]

I've overclocked my Pi3B+ to 1475MHz.

[Imperf3kt]

Has anybody considered underclocking the Pi3b+ and comparing it to a Pi3b?
I'm curious what the temperatures and current draw will be at a similar/same clock frequency.

[W. H. Heydt]

I've overclocked my Pi3B+ to 1475MHz.

And the race is on. Where did I put the popcorn supply? (That sort of thing is, of course, vary from chip to chip. It will be interesting to see what other numbers turn up...and it anyone will try a cryogenic rig....)

[ejolson]

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.

[tkaiser]

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.

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

[jahboater]

From the blog post I assume that the CPU speed boost is only the effect of better thermal management. This raises a few questions:

and also better power supply paths to the ARM cores.

[jamesh]

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.

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

I think you are probably going to have to reduce your sarcastic comments a bit please. Attacking others work is frowned upon here.

[jamesh]

Also worth considering that if you have the HDMI plugged (not apparent in the thermal images) then that cable acts as a heatsink too. In fact any cable plugged in to a socket that is connected to the ground plane will give extra cooling. That can be used to get the heat out of a case...

[rainer.brito]

Great!

So, generally speaking, a Pi 3 B+ without heatsink still cooler than an aluminium heatsinked Pi 3B?

[jamesh]

Great!

So, generally speaking, a Pi 3 B+ without heatsink still cooler than an aluminium heatsinked Pi 3B?

I think its too early to tell. We haven't testing every single heatsink combination possible, so cannot comment on specifics.

[dom]

So, generally speaking, a Pi 3 B+ without heatsink still cooler than an aluminium heatsinked Pi 3B?

If the heatsink is a small and sticks onto the SoC then I'd expect the Pi3+ to be much more effective.
If the heatsink is large (e.g. attached to aluminium case like the FLIRC) then it's not clear and it would need testing.

[killwater]

Seems like a lot of people are interested in this issue.

@rpiMike
Thank you for the link - very informative.

@mahjongg

the main trick is that they have flipped the chip (SoC) upside down, the back of the chip is completely flat and can make excellent thermal contact with the heat spreader that is mounted directly to it, the heat spreader in turn is thermally attached to the ground plane of the PI, so that heat is transferred to all corners of the PI. This much better thermal arrangement makes that the chip isn't such a hot spot as it was before.

Is there a crossection through this arrangement available somewhere? I have hard time visualising it - it sounds like any external heatsink effectiveness would be severely diminished. Is the chip flat on the PCB or flat on the metal plate visible from the outside?

[gregeric]

See https://en.wikipedia.org/wiki/Flip_chip

On the original 2837, the silicon faced upwards with tiny bond wires to connect to the outside world. Now it's been flipped over and, as per that wiki, bond wires done away with. Instead a more or less direct electrical & thermal connection to the PCB.

[jahboater]

See https://en.wikipedia.org/wiki/Flip_chip

On the original 2837, the silicon faced upwards with tiny bond wires to connect to the outside world. Now it's been flipped over and, as per that wiki, bond wires done away with. Instead a more or less direct electrical & thermal connection to the PCB.

And good thermal contact with the heat spreader too by the looks of it.

Mine arrived today

I ran my usual stress test on it with a 15mm cube adafruit heatsink:-

Code: Select all

wget https://raw.githubusercontent.com/ssvb/cpuburn-arm/master/cpuburn-a53.S
gcc -o cpuburn-a53 cpuburn-a53.S
./cpuburn-a53

both the heatsink and the board get hot very quickly, even the usb sockets warm up.
Impressive.
It throttles back to around 1GHz which is better than the Pi3 which went all the way back to 600Mhz (and in the early days would crash the Pi3 in seconds).

[tkaiser]

It throttles back to around 1GHz which is better than the Pi3 which went all the way back to 600Mhz

600 MHz is 'frequency capping' (both clockspeed and supply voltage to the ARM cores was reduced). Curious: while you run cpuburn can you please run in another shell

Code: Select all

perl -e "printf \"%19b\n\", $(vcgencmd get_throttled | cut -f2 -d=)"
vcgencmd measure_volts | cut -f2 -d= | sed 's/000//'

First line prints throttling, under-voltage and frequency capping information, second one should print the Vcore voltage (no idea with 3 B+ but on all older RPi it's that).

Or maybe storing the following as e.g. /usr/local/sbin/raspimon and then execute it in another shell while running cpuburn for a minute?

Code: Select all

#!/bin/bash

echo -e "To stop simply press [ctrl]-[c]\n"
Counter=14
DisplayHeader="Time       Temp  CPU fake/real     Health state    Vcore"
while true ; do
	let Counter++
	if [ ${Counter} -eq 15 ]; then
		echo -e "${DisplayHeader}"
		Counter=0
	fi
	Health=$(perl -e "printf \"%19b\n\", $(vcgencmd get_throttled | cut -f2 -d=)")
	Temp=$(vcgencmd measure_temp | cut -f2 -d=)
	RealClockspeed=$(vcgencmd measure_clock arm | awk -F"=" '{printf ("%0.0f",$2/1000000); }' )
	SysFSClockspeed=$(awk '{printf ("%0.0f",$1/1000); }' </sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq)
	CoreVoltage=$(vcgencmd measure_volts | cut -f2 -d= | sed 's/000//')
	echo -e "$(date "+%H:%M:%S"): ${Temp}$(printf "%5s" ${SysFSClockspeed})/$(printf "%4s" ${RealClockspeed}) MHz $(printf "%019d" ${Health}) ${CoreVoltage}"
	sleep 5 
done

Really curious about the output (especially the Vcore voltage)

[jahboater]

Sure, later this evening.
I have just put one of these new "A1 app performance" class SD cards in.
So it is doing the usual 17 million line C/C++ compilation to get the latest gcc installed - should be interesting to see how much that time is improved by on the 3B+.

This is your script while running the large build (make -j5):

Code: Select all

[email protected]:~ $ ./pistat.sh
To stop simply press [ctrl]-[c]

Time       Temp  CPU fake/real     Health state    Vcore
16:21:17: 66.6'C 1400/1400 MHz 0000000000000000000 1.3625V
16:21:22: 66.6'C 1400/1400 MHz 0000000000000000000 1.3625V
16:21:27: 66.6'C 1400/1400 MHz 0000000000000000000 1.3625V
16:21:33: 65.5'C 1400/1400 MHz 0000000000000000000 1.3625V
16:21:38: 65.5'C 1400/1400 MHz 0000000000000000000 1.3625V

[tkaiser]

This is your script while running the large build (make -j5):

Code: Select all

[email protected]:~ $ ./pistat.sh
To stop simply press [ctrl]-[c]

Time       Temp  CPU fake/real     Health state    Vcore
16:21:17: 66.6'C 1400/1400 MHz 0000000000000000000 1.3625V
16:21:22: 66.6'C 1400/1400 MHz 0000000000000000000 1.3625V
16:21:27: 66.6'C 1400/1400 MHz 0000000000000000000 1.3625V
16:21:33: 65.5'C 1400/1400 MHz 0000000000000000000 1.3625V
16:21:38: 65.5'C 1400/1400 MHz 0000000000000000000 1.3625V

Nice, so it works. And the 1.4GHz DVFS OPP uses 1.3625V. With my Pi 3 I've seen either 1.3312V or 1.3250V at 1.2GHz and once frequency capping happened (cpufreq down to 600 MHz) it was 1.2V instead. I would assume if 1.4GHz uses 1.3625V then the 1.2GHz OPP most probably shows a lower voltage as on the Pi 3.

BTW: Those zeroes above can change. Some can become a 1 as follows:

Code: Select all

1110000000000000010
|||             |||_ under-voltage
|||             ||_ currently throttled
|||             |_ arm frequency capped
|||_ under-voltage has occurred since last reboot
||_ throttling has occurred since last reboot
|_ arm frequency capped has occurred since last reboot

BTW: The following thread is very interesting since this specific Linpack is an excellent choice to check for DVFS under-voltage conditions (happened with Pi 3 2 years ago): viewtopic.php?f=63&t=208167&p=1287237#p1287237 -- maybe you can give xhpl also a try and report back in the other thread?

[jahboater]

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:45:51: 57.5'C 1400/1400 MHz 0000000000000000000 1.3500V
19:45:56: 60.7'C 1400/1400 MHz 0000000000000000000 1.3563V
19:46:01: 62.8'C 1400/1400 MHz 0000000000000000000 1.3563V
19:46:06: 64.5'C 1400/1400 MHz 0000000000000000000 1.3563V
19:46:11: 66.6'C 1400/1400 MHz 0000000000000000000 1.3625V
19:46:17: 67.7'C 1400/1400 MHz 0000000000000000000 1.3625V
19:46:22: 69.8'C 1400/1400 MHz 0000000000000000000 1.3625V
19:46:27: 70.4'C 1400/1200 MHz 0000000000000000000 1.2438V
19:46:33: 69.8'C 1400/1400 MHz 0000000000000000000 1.3625V
19:46:38: 69.8'C 1400/1400 MHz 0000000000000000000 1.3625V
19:46:43: 70.4'C 1400/1200 MHz 0000000000000000000 1.2438V
19:46:49: 70.9'C 1400/1200 MHz 0000000000000000000 1.2438V
19:46:54: 70.9'C 1400/1200 MHz 0000000000000000000 1.2438V
19:46:59: 70.9'C 1400/1200 MHz 0000000000000000000 1.2438V
19:47:04: 70.9'C 1400/1200 MHz 0000000000000000000 1.2438V
Time       Temp  CPU fake/real     Health state    Vcore
19:47:10: 72.0'C 1400/1200 MHz 0000000000000000000 1.2438V
19:47:15: 72.0'C 1400/1200 MHz 0000000000000000000 1.2438V
19:47:20: 72.0'C 1400/1200 MHz 0000000000000000000 1.2438V
19:47:26: 73.1'C 1400/1200 MHz 0000000000000000000 1.2438V
19:47:31: 73.1'C 1400/1200 MHz 0000000000000000000 1.2438V
19:47:36: 73.6'C 1400/1200 MHz 0000000000000000000 1.2438V
19:47:42: 73.6'C 1400/1200 MHz 0000000000000000000 1.2438V
19:47:47: 74.1'C 1400/1200 MHz 0000000000000000000 1.2438V
19:47:52: 74.1'C 1400/1200 MHz 0000000000000000000 1.2438V
19:47:57: 74.1'C 1400/1200 MHz 0000000000000000000 1.2438V
19:48:03: 74.7'C 1400/1200 MHz 0000000000000000000 1.2438V
19:48:08: 75.8'C 1400/1200 MHz 0000000000000000000 1.2438V
19:48:13: 76.3'C 1400/1200 MHz 0000000000000000000 1.2438V
19:48:19: 76.3'C 1400/1200 MHz 0000000000000000000 1.2438V
19:48:24: 76.3'C 1400/1200 MHz 0000000000000000000 1.2438V
Time       Temp  CPU fake/real     Health state    Vcore
19:48:29: 76.8'C 1400/1200 MHz 0000000000000000000 1.2438V
19:48:35: 77.4'C 1400/1200 MHz 0000000000000000000 1.2438V
19:48:40: 77.4'C 1400/1200 MHz 0000000000000000000 1.2438V
19:48:45: 77.4'C 1400/1200 MHz 0000000000000000000 1.2438V
19:48:51: 77.4'C 1400/1200 MHz 0000000000000000000 1.2438V
19:48:56: 77.9'C 1400/1200 MHz 0000000000000000000 1.2438V
19:49:01: 77.9'C 1400/1200 MHz 0000000000000000000 1.2438V
19:49:07: 78.4'C 1400/1200 MHz 0000000000000000000 1.2438V
19:49:12: 78.4'C 1400/1200 MHz 0000000000000000000 1.2438V
19:49:17: 78.4'C 1400/1200 MHz 0000000000000000000 1.2438V
19:49:23: 78.4'C 1400/1200 MHz 0000000000000000000 1.2438V
19:49:28: 78.4'C 1400/1200 MHz 0000000000000000000 1.2438V
19:49:33: 79.5'C 1400/1200 MHz 0000000000000000000 1.2438V
19:49:38: 79.5'C 1400/1200 MHz 0000000000000000000 1.2438V
19:49:44: 79.5'C 1400/1200 MHz 0000000000000000000 1.2438V
Time       Temp  CPU fake/real     Health state    Vcore
19:49:49: 79.5'C 1400/1200 MHz 0100000000000000000 1.2438V
19:49:54: 80.1'C 1400/1195 MHz 0100000000000000010 1.2438V
19:50:00: 79.5'C 1400/1195 MHz 0100000000000000000 1.2438V
19:50:05: 79.5'C 1400/1195 MHz 0100000000000000010 1.2438V
19:50:10: 80.1'C 1400/1141 MHz 0100000000000000000 1.2438V
19:50:16: 80.1'C 1400/1200 MHz 0100000000000000010 1.2438V
19:50:21: 80.6'C 1400/1195 MHz 0100000000000000010 1.2438V
19:50:26: 80.1'C 1400/1141 MHz 0100000000000000010 1.2438V
19:50:32: 80.6'C 1400/1195 MHz 0100000000000000010 1.2438V
19:50:37: 80.1'C 1400/1195 MHz 0100000000000000010 1.2438V
19:50:42: 80.6'C 1400/1195 MHz 0100000000000000010 1.2438V
19:50:48: 80.6'C 1400/1141 MHz 0100000000000000010 1.2438V
19:50:53: 80.1'C 1400/1141 MHz 0100000000000000010 1.2438V
19:50:58: 80.6'C 1400/1195 MHz 0100000000000000010 1.2438V
19:51:03: 80.1'C 1400/1141 MHz 0100000000000000010 1.2438V
Time       Temp  CPU fake/real     Health state    Vcore
19:51:09: 80.6'C 1400/1141 MHz 0100000000000000010 1.2438V

You can see Vcore drops as soon as the freq goes down from 1.4GHz to 1.2GHz, but that doesn't count as throttling yet (see the end).

Back to idle, we get:-

Code: Select all

Time       Temp  CPU fake/real     Health state    Vcore
20:00:50: 38.6'C  600/ 600 MHz 0100000000000000000 1.2V
20:00:55: 39.2'C  600/ 600 MHz 0100000000000000000 1.2V
20:01:00: 39.2'C  600/ 600 MHz 0100000000000000000 1.2V
20:01:05: 39.2'C  600/ 600 MHz 0100000000000000000 1.2V
20:01:10: 39.2'C  600/ 600 MHz 0100000000000000000 1.2V

and the 1.2V

[tkaiser]

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.