ahtoh Posted June 10, 2020 Share Posted June 10, 2020 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) 0 Quote Link to comment Share on other sites More sharing options...
Igor Posted June 10, 2020 Share Posted June 10, 2020 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. 0 Quote Link to comment Share on other sites More sharing options...
devman Posted June 12, 2020 Share Posted June 12, 2020 (edited) 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 0 Quote Link to comment Share on other sites More sharing options...
ahtoh Posted June 12, 2020 Author Share Posted June 12, 2020 Drilled holes in the case to help cooling it 0 Quote Link to comment Share on other sites More sharing options...
tkaiser Posted June 12, 2020 Share Posted June 12, 2020 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. 0 Quote Link to comment Share on other sites More sharing options...
Werner Posted June 12, 2020 Share Posted June 12, 2020 Is there a chance that you could verify the temperature readings with an external probe? 0 Quote Link to comment Share on other sites More sharing options...
@lex Posted June 12, 2020 Share Posted June 12, 2020 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 1 Quote Link to comment Share on other sites More sharing options...
@lex Posted June 12, 2020 Share Posted June 12, 2020 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 ... 0 Quote Link to comment Share on other sites More sharing options...
stavoltafunzia Posted June 12, 2020 Share Posted June 12, 2020 (edited) 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 0 Quote Link to comment Share on other sites More sharing options...
devman Posted June 13, 2020 Share Posted June 13, 2020 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 0 Quote Link to comment Share on other sites More sharing options...
ahtoh Posted June 13, 2020 Author Share Posted June 13, 2020 (edited) 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 0 Quote Link to comment Share on other sites More sharing options...
@lex Posted June 13, 2020 Share Posted June 13, 2020 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... 0 Quote Link to comment Share on other sites More sharing options...
devman Posted June 15, 2020 Share Posted June 15, 2020 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 0 Quote Link to comment Share on other sites More sharing options...
tkaiser Posted June 29, 2020 Share Posted June 29, 2020 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. 0 Quote Link to comment Share on other sites More sharing options...
guidol Posted June 29, 2020 Share Posted June 29, 2020 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_NEO3https://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? 0 Quote Link to comment Share on other sites More sharing options...
tkaiser Posted June 29, 2020 Share Posted June 29, 2020 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? 1 Quote Link to comment Share on other sites More sharing options...
@lex Posted June 29, 2020 Share Posted June 29, 2020 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. 0 Quote Link to comment Share on other sites More sharing options...
guidol Posted June 29, 2020 Share Posted June 29, 2020 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?) 0 Quote Link to comment Share on other sites More sharing options...
guidol Posted June 29, 2020 Share Posted June 29, 2020 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 0 Quote Link to comment Share on other sites More sharing options...
@lex Posted June 29, 2020 Share Posted June 29, 2020 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" 0 Quote Link to comment Share on other sites More sharing options...
tkaiser Posted June 29, 2020 Share Posted June 29, 2020 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: 0 Quote Link to comment Share on other sites More sharing options...
guidol Posted June 29, 2020 Share Posted June 29, 2020 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. 0 Quote Link to comment Share on other sites More sharing options...
Igor Posted June 29, 2020 Share Posted June 29, 2020 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. 0 Quote Link to comment Share on other sites More sharing options...
tkaiser Posted June 29, 2020 Share Posted June 29, 2020 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. 0 Quote Link to comment Share on other sites More sharing options...
Igor Posted June 29, 2020 Share Posted June 29, 2020 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. 0 Quote Link to comment Share on other sites More sharing options...
@lex Posted June 29, 2020 Share Posted June 29, 2020 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. 0 Quote Link to comment Share on other sites More sharing options...
devman Posted June 29, 2020 Share Posted June 29, 2020 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 0 Quote Link to comment Share on other sites More sharing options...
M.FB Posted July 1, 2020 Share Posted July 1, 2020 (edited) 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 0 Quote Link to comment Share on other sites More sharing options...
ahtoh Posted July 2, 2020 Author Share Posted July 2, 2020 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 0 Quote Link to comment Share on other sites More sharing options...
guidol Posted July 10, 2020 Share Posted July 10, 2020 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... 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.