Nanopi R2S overheating and throttling

[ahtoh]

Received my SBC today, installed armbian and run quick tests

Runs very hot (in stock yellow case). Throttles under load and can not run at full 1500Mhz

Below results on armbian measured with armbianmonitor -m

power measured from the wall

71C / 2.5W / 600Mhz idle

85C / 3.7W / 1000Mhz under load (stress -c 4)

 

I also tested without case and results are better but still it throttles under full load. Ambient temperature was about 25C

Is this just me and my unit has faulty heatsink or you also observe similar results?

Any ideas on how to fix this? I see there is a fan header on the board but no fan installed, just the heatsink, but I think the better solution would be to use a metal case that acts as a heatsink. (like Flirc for raspberry pi)

 

[Igor]

32 minutes ago, ahtoh said:

Any ideas on how to fix this? I see there is a fan header on the board but no fan installed, just the heatsink, but I think the better solution would be to use a metal case that acts as a heatsink

This chip is powerful and it runs hot, in a small box its just worse. Nothing is wrong with your device, nor software ... a fan or clocking it down by default is the only solution.

[devman]

Quote

71C / 2.5W / 600Mhz idle

85C / 3.7W / 1000Mhz under load (stress -c 4)

I'm seeing similar results on my unit, although mine throttled a bit further (816 MHz @15 minutes) if you leave it running.
In that little case with token ventilation holes, there's just nowhere for the heat to go. 

 

I'll retest tonight without the case. 

Edited June 12, 2020 by devman
added time to throttle

[ahtoh]

Drilled holes in the case to help cooling it

 

[tkaiser]

On 6/10/2020 at 9:23 PM, Igor said:

This chip is powerful and it runs hot, in a small box its just worse. Nothing is wrong with your device, nor software ... a fan or clocking it down by default is the only solution.

 

This is a Renegade featuring the same 'powerful and hot running' RK3328 with large passive heatsink without enclosure:

 ____                                 _      
|  _ \ ___ _ __   ___  __ _  __ _  __| | ___ 
| |_) / _ \ '_ \ / _ \/ _` |/ _` |/ _` |/ _ \
|  _ <  __/ | | |  __/ (_| | (_| | (_| |  __/
|_| \_\___|_| |_|\___|\__, |\__,_|\__,_|\___|
                      |___/                  
Welcome to Armbian buster with Linux 5.4.8-rockchip64

System load:   0.24 0.05 0.02  	Up time:       41 days		
Memory usage:  12 % of 1986MB 	Zram usage:    7 % of 993Mb  	IP:            192.168.83.251
CPU temp:      46°C           	
Usage of /:    40% of 7.3G   	storage/:      16% of 7.3T   	

Last login: Sun May 31 12:39:32 2020 from 192.168.83.186

tk@renegade:~$ sudo -s
[sudo] password for tk: 
root@renegade:/home/tk# armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.

07:31:13: 1296MHz  0.20   0%   0%   0%   0%   0%   0% 45.9°C  0/6
07:31:18:  408MHz  0.19   0%   0%   0%   0%   0%   0% 42.7°C  0/6
07:31:23:  408MHz  0.17   2%   1%   1%   0%   0%   0% 39.5°C  0/6
07:31:29:  408MHz  0.16   1%   0%   0%   0%   0%   0% 44.1°C  0/6
07:31:34:  408MHz  0.14   1%   0%   0%   0%   0%   0% 42.3°C  0/6
07:31:39:  408MHz  0.13   1%   0%   0%   0%   0%   0% 41.8°C  0/6
07:31:44:  408MHz  0.12   1%   0%   0%   0%   0%   0% 43.2°C  0/6
07:31:49: 1296MHz  0.33   2%   1%   0%   0%   0%   0% 47.3°C  0/6
07:31:55:  408MHz  0.30   1%   0%   0%   0%   0%   0% 41.8°C  0/6^C

Rock64 is based on the very same RK3328 SoC, my board has just a laughable tiny heatsink on the SoC and all of the 8 sbc-bench results collected here https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md were done without active cooling. Even with the most demanding cpuminer benchmark the SoC temperature was never reported as above 70°C and running cpuminer at 1.4GHz was possible without any throttling.

 

This is NanoPi R2S using the very same RK3328 doing exactly nothing at all at around or above 70°C: https://tech.scargill.net/nanopi-r2s-openwrt-minirouter/

 

If idle temperatures of NanoPi R2S without that little yellow plastic oven are above 50°C then there's clearly something wrong (maybe something trivial as a wrong supply voltage resulting in the thermal sensor reporting BS just as we saw on Orange Pi Zero). Utilizing FriendlyELEC's little yellow plastic oven of course will result in insane temperatures.

[Werner]

Is there a chance that you could verify the temperature readings with an external probe?

[@lex]

6 hours ago, tkaiser said:

This is NanoPi R2S using the very same RK3328 doing exactly nothing at all at around or above 70°C: https://tech.scargill.net/nanopi-r2s-openwrt-minirouter/

 

Wrong CPU_GOVERNOR and no way to dissipate the heat from inside the enclosure leads to overheating.

 

Some very simple benchmarks on recent kernel:

https://github.com/avafinger/nanopi-r2s-ubuntu-server-minimal-image

 

[@lex]

It is also important to check if the thermal pad touches the CPU, someone noticed the spacer is higher than it should be. Remove the board from the case and look against a light source, if you see a gap, you have a problem ...

[stavoltafunzia]

On 6/10/2020 at 8:49 PM, ahtoh said:

 

Received my SBC today, installed armbian and run quick tests

Runs very hot (in stock yellow case). Throttles under load and can not run at full 1500Mhz

Below results on armbian measured with armbianmonitor -m

power measured from the wall

71C / 2.5W / 600Mhz idle

85C / 3.7W / 1000Mhz under load (stress -c 4)

 

I also tested without case and results are better but still it throttles under full load. Ambient temperature was about 25C

Is this just me and my unit has faulty heatsink or you also observe similar results?

Any ideas on how to fix this? I see there is a fan header on the board but no fan installed, just the heatsink, but I think the better solution would be to use a metal case that acts as a heatsink. (like Flirc for raspberry pi)

 

I'm experiencing similar temperatures with the yellow case. I checked the board and the thermal pad adheres well to the soc and the heatsink. I think the only solution indeed is the aluminium case. I ordered one few days ago, but still it hasn't arrived yet so cannot say anything about its performance.

Edited June 12, 2020 by stavoltafunzia

[devman]

Idle temps drop by ~10c without the enclosure. No issues with connections between the heatsink and the cpu.

 

No enclosure, thermal pad:

 _   _                         _   ____  ____  ____
| \ | | __ _ _ __   ___  _ __ (_) |  _ \|___ \/ ___|
|  \| |/ _` | '_ \ / _ \| '_ \| | | |_) | __) \___ \
| |\  | (_| | | | | (_) | |_) | | |  _ < / __/ ___) |
|_| \_|\__,_|_| |_|\___/| .__/|_| |_| \_\_____|____/
                        |_|
Welcome to Armbian Bionic with Linux 5.4.45-rockchip64

System load:   0.00 0.00 0.00   Up time:       33 min
Memory usage:  17 % of 472MB    IP:            169.254.9.92 192.168.86.36
CPU temp:      61°C
Usage of /:    4% of 29G

[ General system configuration (beta): armbian-config ]

Last login: Sat Jun 13 02:52:34 2020 from 192.168.86.28

james@r2s:~$ sudo -s
[sudo] password for james:
root@r2s:~# armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.

03:13:31:  600MHz  0.00   0%   0%   0%   0%   0%   0% 59.5°C  0/6
03:13:36:  600MHz  0.00   0%   0%   0%   0%   0%   0% 58.6°C  0/6
03:13:41:  600MHz  0.00   0%   0%   0%   0%   0%   0% 58.6°C  0/6
03:13:46:  600MHz  0.00   0%   0%   0%   0%   0%   0% 58.2°C  0/6
03:13:52:  600MHz  0.00   0%   0%   0%   0%   0%   0% 57.7°C  0/6
03:13:57:  600MHz  0.00   0%   0%   0%   0%   0%   0% 58.2°C  0/6
03:14:02:  600MHz  0.00   0%   0%   0%   0%   0%   0% 57.7°C  0/6

No enclosure, copper shim:

 _   _                         _   ____  ____  ____
| \ | | __ _ _ __   ___  _ __ (_) |  _ \|___ \/ ___|
|  \| |/ _` | '_ \ / _ \| '_ \| | | |_) | __) \___ \
| |\  | (_| | | | | (_) | |_) | | |  _ < / __/ ___) |
|_| \_|\__,_|_| |_|\___/| .__/|_| |_| \_\_____|____/
                        |_|
Welcome to Armbian Bionic with Linux 5.4.45-rockchip64

System load:   0.00 0.00 0.00   Up time:       30 min
Memory usage:  17 % of 472MB    IP:            169.254.11.84 192.168.86.36
CPU temp:      59°C
Usage of /:    4% of 29G

[ General system configuration (beta): armbian-config ]

Last login: Sat Jun 13 03:13:22 2020 from 192.168.86.28

james@r2s:~$ sudo -s
[sudo] password for james:
root@r2s:~# armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.

03:47:30:  600MHz  0.07   0%   0%   0%   0%   0%   0% 55.5°C  0/6
03:47:35:  600MHz  0.07   0%   0%   0%   0%   0%   0% 54.6°C  0/6
03:47:40:  600MHz  0.06   0%   0%   0%   0%   0%   0% 56.8°C  0/6
03:47:46:  600MHz  0.06   0%   0%   0%   0%   0%   0% 56.4°C  0/6
03:47:51:  600MHz  0.05   0%   0%   0%   0%   0%   0% 56.4°C  0/6
03:47:56:  600MHz  0.05   0%   0%   0%   0%   0%   0% 56.4°C  0/6
03:48:01:  600MHz  0.04   0%   0%   0%   0%   0%   0% 57.3°C  0/6

 

[ahtoh]

The holes helped. I placed it next to the switch where it gets cooled by the switch fan.

Ran some wireguard benchmarks, the cpu load in percentage is roughly equals Mbyte/s throughput.

The default CPU_GOVERNOR is on_demand I beleive

 

I also noticed the thermal pad is maybe too thin, but there is no gap as I can see

Edited June 13, 2020 by ahtoh

[@lex]

9 hours ago, devman said:

03:47:30: 600MHz

That is an indication of wrong CPU_GOVERNOR, yes you get nice benchmarks values for a very short period of time and then the board overheats.

 

7 hours ago, ahtoh said:

The default CPU_GOVERNOR is on_demand I beleive

 

just check with:

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
ondemand
ondemand
ondemand
ondemand

 

I think the holes are the best workaround...

[devman]

Looks it's reacting correctly compared to the settings it's being fed. 

james@r2s:~$ cat /etc/default/cpufrequtils
ENABLE=true
MIN_SPEED=600000
MAX_SPEED=1390000
GOVERNOR=ondemand

james@r2s:~$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
ondemand
ondemand
ondemand
ondemand

[tkaiser]

On 6/13/2020 at 5:50 AM, devman said:

Idle temps drop by ~10c without the enclosure. No issues with connections between the heatsink and the cpu.

 

So there's something seriously wrong with this hardware or kernel code. 60°C is something noticeable by 'thumb test'. Does it hurt if you press your thumb on the heatsink while Armbian reports above 55°C SoC temperature?

 

Have you done a test with an image using Rockchip's BSP kernel (4.4)? Just to compare which temperatures are reported there?

 

@@lex Why do you think a reported clockspeed of 600 MHz in idle would be an indication of wrong governor? Igor defined 600 MHz for whatever reasons half a year ago as minimum clockspeed but there shouldn't be much of a difference between the 408 MHz before and 600 MHz now.

[guidol]

I hope that the NanoPi Neo3 wouldnt get that heat-problems, because it seems to get the same CPU as the R2S ;(
http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO3
https://www.cnx-software.com/2020/06/29/tiny-nanopi-neo3-sbc-targets-networked-storage-with-gbe-and-usb-3-0/

 

The Allwinner CPUs were - as of my point of view - not getting that hot as the Rockchip-CPUs.

If we would ever see a NanoPi Neo6 with H6-CPU?

[tkaiser]

25 minutes ago, guidol said:

that hot as the Rockchip-CPUs.

 

Are you kidding? Again: 

 

There's no problem with the RK3328, this is just another boring Quad-Core A53 in 28nm (just like the H6). So the question remains what's wrong with NanoPi R2S and not the RK SoCs.

 

And I really don't understand why so many blindly trust in numbers. There's a thermal sensor inside the SoC, there's a reference voltage, there's some calibration needed, there's driver code. The idea that the numbers this driver spits out are somewhat or even closely related to the actual temperature of the SoC in question is just a hope!

 

Care to remember what you yourself already reported?

 

[@lex]

7 hours ago, tkaiser said:

 

So there's something seriously wrong with this hardware or kernel code. 60°C is something noticeable by 'thumb test'. Does it hurt if you press your thumb on the heatsink while Armbian reports above 55°C SoC temperature?

 

Have you done a test with an image using Rockchip's BSP kernel (4.4)? Just to compare which temperatures are reported there?

 

@@lex Why do you think a reported clockspeed of 600 MHz in idle would be an indication of wrong governor? Igor defined 600 MHz for whatever reasons half a year ago as minimum clockspeed but there shouldn't be much of a difference between the 408 MHz before and 600 MHz now.

My assertion was based on guessing...

 

On 6/13/2020 at 2:58 AM, ahtoh said:

CPU_GOVERNOR is on_demand I beleive

 

Practical experiments here indicated that the performance governor and 600 MHz heated up the board very soon in idle mode, 408 MHz and ondemand is acceptable for a mini router inside the case, around 55 ºC on a long run (ambient temp ~22 ºC). It is possible to run CPU at 1.5 GHz and change CPU throttling to start at 80 ºC  , nothing that a swiss cheese and convection can't help.

 

Perhaps the heat sink pad is a bit thick and a copper shim (or many) would help a lot, but the whole board is heated up and i suppose it should.

[guidol]

On 6/12/2020 at 3:23 PM, @lex said:

 

Wrong CPU_GOVERNOR and no way to dissipate the heat from inside the enclosure leads to overheating.

which is the wrong and which is the right governor? (and maybe why?)

[guidol]

2 hours ago, tkaiser said:

 

Are you kidding? Again:  (Renegade)

 

There's no problem with the RK3328, this is just another boring Quad-Core A53 in 28nm (just like the H6). So the question remains what's wrong with NanoPi R2S and not the RK SoCs.

 

And I really don't understand why so many blindly trust in numbers. There's a thermal sensor inside the SoC, there's a reference voltage, there's some calibration needed, there's driver code. The idea that the numbers this driver spits out are somewhat or even closely related to the actual temperature of the SoC in question is just a hope!

 

Care to remember what you yourself already reported?

 

@tkaiser nice to read you
No Iam not kidding, but you are also right that something must be differnt on the R2S against the Renegade.
In my mind: when one company could - reading teh temperature -  get right to work (Renegade), then it shouldnt be hard for another company to gain the same result.

Maybe the RK3328 isnt nowthing like a Quadcore-A53, but its working and we will loose the Allwinner H5.
So FriendyARM sint taking the H6 and do try to be "friendly" to Rockchip

I personally dont understand what the problem - in the year 2020 - to get a correct temperature-readout or usinf the right voltage for a chipset?
On the other hand the last 1-2 years FriendlyARM has some better meta-cases like other companys

 

I remember what I did wrote, but the hope isnt gone that we do get a good temperature-readout, when the SBCs do so much more the right "boring" way

[@lex]

6 minutes ago, guidol said:

which is the wrong and which is the right governor? (and maybe why?)

Good question, i would say wrong when the CPU throttling kicks in too soon without load. I would stick to that tires vendor... "Power is nothing without control"

[tkaiser]

37 minutes ago, @lex said:

Practical experiments here indicated that the performance governor and 600 MHz heated up the board very soon in idle mode

 

What?

 

There's no difference between 408 MHz and 600 MHz since the DVFS OPP for both are pretty low.

 

That's RK3328 powered Renegade idling at 408 MHz:

root@renegade:/home/tk# armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.

12:47:02: 1296MHz  0.19   1%   1%   0%   0%   0%   0% 45.5°C  0/5
12:47:07:  408MHz  0.17   2%   1%   0%   0%   0%   0% 43.6°C  0/5
12:47:12:  408MHz  0.16   1%   0%   0%   0%   0%   0% 45.0°C  0/5
12:47:17:  408MHz  0.15   1%   0%   0%   0%   0%   0% 44.1°C  0/5
12:47:23:  408MHz  0.13   1%   0%   0%   0%   0%   0% 42.7°C  0/5
12:47:28:  408MHz  0.12   1%   0%   0%   0%   0%   0% 44.5°C  0/5
12:47:33: 1296MHz  0.11   1%   1%   0%   0%   0%   0% 46.4°C  0/5^C

That's the exact same hardware with exact same load when setting minimum cpufreq to 600 MHz (no idea why @Igor did this change back in November though, the 600 MHz are not the result of the cpufreq governor doing anything but of the project's owner commiting some changes for whatever reason):

root@renegade:/home/tk# armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.

13:42:02: 1296MHz  0.00   2%   0%   1%   0%   0%   0% 43.6°C  0/5
13:42:07:  600MHz  0.00   0%   0%   0%   0%   0%   0% 44.5°C  0/5
13:42:12: 1296MHz  0.00   2%   1%   0%   0%   0%   0% 44.5°C  0/5
13:42:17:  600MHz  0.00   0%   0%   0%   0%   0%   0% 43.2°C  0/5
13:42:23:  600MHz  0.00   1%   0%   0%   0%   0%   0% 43.6°C  0/5
13:42:28:  600MHz  0.00   1%   0%   0%   0%   0%   0% 43.6°C  0/5
13:42:33:  600MHz  0.00   0%   0%   0%   0%   0%   0% 45.0°C  0/5
13:42:38:  600MHz  0.00   0%   0%   0%   0%   0%   0% 44.1°C  0/5^C

And now compare with @devman's results above using R2S without the yellow plastic oven which are still close to 15°C above Renegade/Rock64. So it's obviously not an RK3328 problem users are talking here about!

 

Wrt ondemand governor. This governor has some tunables that need to be set accordingly depending on kernel version. But since nobody in Armbian gives a sh*t about such low level stuff, it's as it is. This most probably would need some attention: https://github.com/armbian/build/blob/master/packages/bsp/common/usr/lib/armbian/armbian-hardware-optimization#L81-L83 

 

The last time I asked for testers I got zero useful responses:

 

 

[guidol]

7 minutes ago, tkaiser said:

 

That's the exact same hardware with exact same load when setting minimum cpufreq to 600 MHz (no idea why @Igor did this change back in November though, the 600 MHz are not the result of the cpufreq governor doing anything but of the project's owner commiting some changes for whatever reason)

 

If I read your following post, then I would think (like @Igor) it would be a good idea to go with a value like 600Mhz?:

 

Quote

But please be careful: setting minimum cpufreq to really low values is counterproductive with some cpufreq governors since it will take a high amount of time to increase cpufreq when needed. @zador.blood.stained and me tested extensively two years ago with a lot of H3 boards and back then we found that setting boards to ~500 MHz minimum was the best compromise. When looking at temperatures or consumption there's literally zero difference between idling at 240 MHz or 480 MHz. The only important thing is DVFS (entering a state where the CPU is fed with lowest voltage possible -- so on those H3 boards with primitive voltage regulation most probably idle behaviour at 240 MHz and 816 MHz doesn't differ that much or at all).

 

Keeping minimum clockspeed at a sensible high value is especially important when thinking about storage performance since some cpufreq governors don't count I/O activity as an indication to increase CPU clockspeeds. For example SD card performance on Tinkerboard with TinkerOS sucked but not with Armbian. Only real difference: the kernel allows to downclock to 200 MHz while with Armbian our cpufrequtils package keeps minimum clockspeed at 600 MHz.

 

[Igor]

7 minutes ago, tkaiser said:

That's the exact same hardware with exact same load when setting minimum cpufreq to 600 MHz (no idea why @Igor did this change back in November though, the 600 MHz are not the result of the cpufreq governor doing anything but of the project's owner commiting some changes for whatever reason):

I don't recall why I did that, probably just adding previously absent MIN number? Certainly not related to R2S. It can surely be adjusted since circumstances changed, but I doubt that will contribuite to any significant temp drop in case of R2S.

 

10 minutes ago, tkaiser said:

But since nobody in Armbian gives a sh*t about such low level stuff, it's as it is. This most probably would need some attention:

 

Armbian is about low level stuff, but we have to be realistic - we solve what we can. We have 1000x more (potential) tasks than ability to solve them ... and this is unlikely to be changed if it hasn't been changed in several years.

[tkaiser]

1 hour ago, Igor said:

I don't recall why I did that

 

Well, that's why commit comments exist. The rockchip64 kernel has the following cpufreq OPP: 408000 600000 816000 1008000 1200000 1296000

 

So setting 600 MHz didn't do a lot other than causing confusion. A third of this thread's posts deal with cpufreq governor confusion wrongly assuming the SoC being on 600 MHz would be the root cause for the thermal anomalies R2S is plagued with.

 

Anyway, this whole thread is bizarre. Why do users not simply verify the numbers some driver spits out? Why blindly trusting in numbers? Those users having the hardware right in front of them could've tested long ago whether the thermal readouts are BS or the hardware. Simply using their thumb and putting it on the heatsink. 

[Igor]

1 hour ago, tkaiser said:

Simply using their thumb and putting it on the heatsink. 

40-47° with IR meter on the surface of yellow box. Running at 600, idle, CPU temp reported 70°. Going down to 408 ... CPU temp remains 68-70°. Applied force cooling for a while drops to 65°, casing stays below 40° and I will update later ... 

Edit:
After 33m:
Max temp on casing 45°. CPU 65-66°

After 60m:

Max temp on casing 46°. CPU 66-67°

Not the most scientific way, but yes, a bit cooler if set CPU_MIN to 408.

[@lex]

Nothing wrong with the board.

Just for reference while comparing it with Renegade:

Renegate size; 4.76 x 2.99 x 1.02 inches
NanoPi R2S size: 2.36 x 1.16 x 2.36 inches

 

Some info, Average consumption idling while cron is running is 1.8W, and i have observed for a while that the board was running with 1.0W ~ 1.2W ,  yes 1 Watt! As soon as cron and systemd-journald and systemd-udevd start working i get 2.0  ~ 2.2W.

Kernel tested is essentially the Armbian Kernel (5.7) and vanilla mainline Kernel (5.8), but the booloader is based on Android (i think) found on internet (can't recall from where i got it, but is old version), no control about the DDR4 dram speed and i think it is very low freq, i maybe wrong. Obviously in my case with less running process, lower the CPU Temp will be.

 

I did the Thumb test, seems consistent with the numbers. I have noticed that FE has now a tinny fan for the new version.

 

 

[devman]

3 minutes ago, Igor said:

40-47° with IR meter on the surface of yellow box. Running at 600, idle, CPU temp reported 70°. Going down to 408 ... CPU temp remains 68-70°. Applied force cooling for a while drops to 65°, casing stays below 40° and I will update later ...

 

Numbers look not far from where I am now.  R2S says 64c, Cheap IR thermometer on the underside of the PCB gives me 48-50c, thumb says "ouch", and I can't get a reliable reading off the heatsink.

 

Temp here is 30c ambient

 

 

[M.FB]

Hello all,

 

Just want to add my experience to this interesting post. First I've did a lot of holes in the yellow case as @ahtoh did, same behavior, then I've got a heatsink with fan, with this the temp in a idle status drops to ~40º just after boot, the temperature on the room is 22ºC-24ºC:

 

 

Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.

2:27:40: 1200MHz  0.34   9%   4%   4%   0%   0%   0% 43.2°C  0/6
22:27:45:  600MHz  0.31   3%   0%   2%   0%   0%   0% 40.5°C  0/6
22:27:50:  600MHz  0.29   1%   0%   0%   0%   0%   0% 41.4°C  0/6
 

Yes, I've removed the screw that is in the heatsink :-)

 

I've put the R2S in the drilled box, more or less the same temp while the CPU was idle, perhaps a couple of degree more, but once the CPU was working with load, the fan was not able to dissipate the heat and once again, ~60ºC while the CPU was idle. As workaround I did a big square hole just on top of the heatsink, whit this the temp raises up to 86ºC on full load, the CPU suffer to maintain the max MHz but returns to ~45ºC once is idle:

 

 

 

Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.

22:15:09: 1200MHz  1.01   7%   0%   7%   0%   0%   0% 53.3°C  0/6
22:15:14:  600MHz  0.93   1%   0%   0%   0%   0%   0% 50.8°C  0/6
22:15:19:  600MHz  0.85   2%   0%   1%   0%   0%   0% 52.5°C  0/6
22:15:24:  600MHz  0.78   1%   0%   0%   0%   0%   0% 50.4°C  0/6
22:15:30:  600MHz  0.72   4%   2%   2%   0%   0%   0% 51.2°C  0/6
22:15:35:  600MHz  0.66   1%   0%   0%   0%   0%   0% 51.7°C  0/6
22:15:40: 1512MHz  0.93  60%   0%  59%   0%   0%   0% 78.5°C  0/6 <== stress -c 4 start
22:15:45: 1512MHz  1.18 100%   0%  99%   0%   0%   0% 81.9°C  0/6
22:15:50: 1512MHz  1.40 100%   0%  99%   0%   0%   0% 80.8°C  0/6
22:15:55: 1512MHz  1.61 100%   0%  99%   0%   0%   0% 84.6°C  0/6
22:16:01: 1296MHz  1.80 100%   0%  99%   0%   0%   0% 85.0°C  0/6
22:16:06: 1512MHz  1.98 100%   0%  99%   0%   0%   0% 84.2°C  0/6
22:16:11: 1512MHz  2.14 100%   0%  99%   0%   0%   0% 83.8°C  0/6
22:16:16: 1512MHz  2.29 100%   0%  99%   0%   0%   0% 85.4°C  1/6
22:16:21: 1296MHz  2.43 100%   0%  99%   0%   0%   0% 84.6°C  0/6
22:16:27: 1512MHz  2.55 100%   0%  99%   0%   0%   0% 82.7°C  0/6
22:16:32: 1512MHz  2.67 100%   0%  99%   0%   0%   0% 86.2°C  1/6
22:16:37: 1512MHz  2.78 100%   0%  99%   0%   0%   0% 85.0°C  1/6
22:16:42: 1296MHz  2.87 100%   0%  99%   0%   0%   0% 83.8°C  0/6
22:16:47: 1512MHz  2.96 100%   0%  99%   0%   0%   0% 84.2°C  0/6
22:16:52: 1296MHz  3.05 100%   0%  99%   0%   0%   0% 86.2°C  0/6
22:16:58: 1512MHz  3.12 100%   0%  99%   0%   0%   0% 83.8°C  0/6
22:17:03: 1296MHz  3.19 100%   0%  99%   0%   0%   0% 85.4°C  0/6
22:17:08: 1512MHz  3.26 100%   0%  99%   0%   0%   0% 84.6°C  2/6
22:17:13: 1512MHz  3.45 100%   0%  99%   0%   0%   0% 83.1°C  1/6 <== stress -c 4 stop
22:17:18:  600MHz  3.17  19%   0%  18%   0%   0%   0% 62.1°C  0/6
22:17:23:  600MHz  2.92   1%   0%   0%   0%   0%   0% 58.2°C  0/6
22:17:29:  600MHz  2.68   1%   0%   0%   0%   0%   0% 56.4°C  0/6
22:17:34:  600MHz  2.47   1%   0%   0%   0%   0%   0% 56.8°C  0/6
22:17:39:  600MHz  2.27   1%   0%   0%   0%   0%   0% 56.4°C  0/6
22:17:44:  600MHz  2.09   0%   0%   0%   0%   0%   0% 55.0°C  0/6
22:17:49:  600MHz  1.92   0%   0%   0%   0%   0%   0% 54.2°C  0/6

 

I've asked to FriendlyARM and they told me that are working to offer a metallic case.

 

Best regards (and sorry for my english)  :-)

 

 

Edited July 1, 2020 by M.FB

[ahtoh]

On 6/29/2020 at 11:01 AM, tkaiser said:

Why blindly trusting in numbers?

 

Are you questioning the Frequency numbers of Temperature?

I don't care whether the temperature is 80 or 50 but I do clearly see throttling and this is what I care about

 

[guidol]

NanoPi Neo3 could now ordered - but not with a metalic case. Dont know how it will heat up in there
https://www.friendlyarm.com/index.php?route=product/product&product_id=279&search=neo3&description=true&category_id=0&sub_category=true

 

And with this cas you couldnt use the 2 additional 2 USB 2.0 ports or fan-support.... which is available on the pin headers...

[winit_a]

Reducing CPU space and heatsinks
Use the iron leaf to reduce the height, elongation, heat sink
Use the MX-4  thermal compound instead of the patch.
Helps to reduce by 10 degrees