billybangleballs Posted March 5, 2017 Share Posted March 5, 2017 Of the 10 columns of output, only 4 seem to be working. Time, CPU Frequency, Load & Temperature. The other 6 columns seem wrong. I'm running Armbian_5.25_Orangepizero_Debian_jessie_default_3.4.113.img Running minerd --benchmark on the console and armbianmonitor -m in a ssh session produces this :- Time CPU load %cpu %sys %usr %nice %io %irq CPU 06:25:10: 240MHz 0.13 1% 0% 0% 0% 0% 0% 47°C 06:25:16: 1200MHz 0.36 1% 0% 0% 0% 0% 0% 64°C 06:25:21: 912MHz 0.65 1% 0% 0% 0% 0% 0% 68°C 06:25:26: 912MHz 0.92 1% 0% 0% 0% 0% 0% 65°C 06:25:31: 912MHz 1.17 1% 0% 0% 0% 0% 0% 69°C 06:25:36: 912MHz 1.39 1% 0% 0% 0% 0% 0% 66°C 06:25:42: 768MHz 1.60 1% 0% 0% 0% 0% 0% 67°C <snip> 06:48:45: 768MHz 4.01 2% 0% 1% 0% 0% 0% 73°C 06:48:51: 768MHz 4.01 2% 0% 1% 0% 0% 0% 73°C 06:48:56: 768MHz 4.01 2% 0% 1% 0% 0% 0% 73°C 06:49:01: 768MHz 4.08 2% 0% 1% 0% 0% 0% 72°C 06:49:06: 768MHz 4.07 2% 0% 1% 0% 0% 0% 72°C 06:49:11: 768MHz 4.07 2% 0% 1% 0% 0% 0% 72°C 06:49:17: 768MHz 4.06 2% 0% 1% 0% 0% 0% 72°C 06:49:22: 768MHz 4.06 2% 0% 1% 0% 0% 0% 72°C <snip> Killing minerd causes the load and temperature to drop back to normal. 06:56:44: 768MHz 4.08 3% 0% 2% 0% 0% 0% 72°C 06:56:49: 768MHz 4.07 3% 0% 2% 0% 0% 0% 72°C 06:56:54: 240MHz 4.06 3% 0% 2% 0% 0% 0% 71°C 06:56:59: 240MHz 3.74 3% 0% 2% 0% 0% 0% 64°C 06:57:05: 240MHz 3.44 3% 0% 2% 0% 0% 0% 62°C 06:57:10: 240MHz 3.16 3% 0% 2% 0% 0% 0% 61°C 06:57:15: 240MHz 2.91 3% 0% 2% 0% 0% 0% 57°C 06:57:20: 240MHz 2.68 3% 0% 2% 0% 0% 0% 52°C 06:57:26: 240MHz 2.46 3% 0% 2% 0% 0% 0% 49°C 06:57:31: 240MHz 2.27 3% 0% 2% 0% 0% 0% 47°C 06:57:36: 240MHz 2.08 3% 0% 2% 0% 0% 0% 46°C 06:57:42: 240MHz 1.92 3% 0% 2% 0% 0% 0% 47°C 06:57:47: 240MHz 1.76 3% 0% 2% 0% 0% 0% 48°C 06:57:52: 240MHz 1.57 3% 0% 2% 0% 0% 0% 46°C The CPU throttling is working fine, but I'm sure all those 0%'s can't be right. The CPU is going as fast as it can without melting, yet it only registers at 2-3%. Is this normal? Link to comment Share on other sites More sharing options...
tkaiser Posted March 5, 2017 Share Posted March 5, 2017 3 hours ago, billybangleballs said: Is this normal? Don't know, running mainline kernel on all H3/H2+ devices here and there it works: root@orangepiplus2e:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU 10:17:28: 1296MHz 0.89 15% 13% 1% 0% 0% 0% 45.3°C 10:17:33: 1008MHz 0.98 15% 13% 1% 0% 0% 0% 41.8°C 10:17:38: 1104MHz 0.98 18% 14% 1% 0% 1% 0% 43.7°C 10:17:43: 816MHz 0.98 18% 16% 1% 0% 0% 0% 41.1°C 10:17:48: 816MHz 0.98 18% 16% 1% 0% 0% 0% 41.2°C 10:17:53: 816MHz 0.98 18% 16% 1% 0% 0% 0% 40.1°C 10:17:58: 960MHz 0.99 22% 16% 4% 0% 0% 0% 40.7°C 10:18:03: 1008MHz 0.99 22% 16% 4% 0% 0% 0% 39.6°C 10:18:08: 960MHz 0.99 20% 15% 1% 0% 1% 0% 39.6°C 10:18:14: 480MHz 0.99 18% 15% 1% 0% 0% 0% 39.2°C 10:18:19: 1008MHz 0.99 18% 15% 1% 0% 0% 0% 40.3°C 10:18:24: 480MHz 1.07 19% 16% 1% 0% 0% 0% 39.5°C 10:18:29: 648MHz 1.07 19% 16% 1% 0% 0% 0% 39.0°C^C root@orangepiplus2e:~# uname -a Linux orangepiplus2e 4.10.1-sun8i #2 SMP Thu Mar 2 18:38:29 CET 2017 armv7l armv7l armv7l GNU/Linux The armbianmonitor script in this scenario either tries to interpret /proc/stat directly or in case it detects a running rpimonitorhelper daemon running (as part of Armbian's RPi-Monitor installation) then it uses /tmp/cpustat instead to save some CPU cycles. Maybe there's something wrong. Very low priority to fix since we implemented this only for a single reason: Giving users a simple monitoring solution to help us identifying their problems (eg. high %iowait values is an indication for 'storage too slow' and not 'CPU overloaded'). Unfortunately this almost never happened. Simple workaround: Use 'iostat $samplerate' eg 'sudo iostat 5' in another shell. Will then print statistics every 5 seconds that look like this: avg-cpu: %user %nice %system %iowait %steal %idle 6.48 0.00 16.01 13.16 0.00 64.35 1 Link to comment Share on other sites More sharing options...
billybangleballs Posted March 5, 2017 Author Share Posted March 5, 2017 Thanks for taking the time to reply, I feel a little more educated now. Last week I didn't know the difference between legacy and mainline but it is becoming clearer. Link to comment Share on other sites More sharing options...
TonyMac32 Posted March 7, 2017 Share Posted March 7, 2017 I can confirm this, thank you for the info, on the NanoPi NEO Air I'm getting similar results testing my heat sink solution: Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU 01:47:08: 912MHz 0.53 0% 0% 0% 0% 0% 0% 33°C 01:47:13: 240MHz 0.49 0% 0% 0% 0% 0% 0% 33°C 01:47:18: 240MHz 0.49 0% 0% 0% 0% 0% 0% 33°C 01:47:24: 240MHz 0.45 0% 0% 0% 0% 0% 0% 33°C <snip> 01:51:12: 912MHz 3.87 0% 0% 0% 0% 0% 0% 45°C 01:51:17: 912MHz 3.88 0% 0% 0% 0% 0% 0% 46°C 01:51:22: 912MHz 3.89 0% 0% 0% 0% 0% 0% 46°C 01:51:28: 912MHz 3.90 0% 0% 0% 0% 0% 0% 46°C 01:51:33: 912MHz 3.91 0% 0% 0% 0% 0% 0% 46°C 01:51:38: 912MHz 3.92 0% 0% 0% 0% 0% 0% 46°C 01:51:43: 912MHz 3.92 0% 0% 0% 0% 0% 0% 46°C 01:51:48: 912MHz 3.93 0% 0% 0% 0% 0% 0% 46°C 01:51:54: 912MHz 3.94 0% 0% 0% 0% 0% 0% 46°C 01:51:59: 912MHz 3.94 0% 0% 0% 0% 0% 0% 46°C <snip> 01:54:39: 912MHz 4.08 0% 0% 0% 0% 0% 0% 49°C At least the heatsink works, I used thermally conductive epoxy to attach a fair-sized heatsink to the CPU, that thermal pad they give is not very good. It appeared to level off at around 52 C 15 minutes in. 1 Link to comment Share on other sites More sharing options...
tkaiser Posted March 12, 2017 Share Posted March 12, 2017 Can't reproduce neither with 5.24 nor latest official release (see output there, especially around '14:03:45' since then I tested with stress -c 4 and then -d 2 to create %usr and %iowait utilization) But I've to admit that I installed RPi-Monitor there (so 'armbianmonitor -m' doesn't query /proc/stat but pre-processed /tmp/cpustat instead). So in case you want to help nailing the problem down check your installation or at least report whether you're running with active rpimonitor-helper or not: tk@orangepizero:~$ ps auxww | grep rpi root 539 0.2 0.5 4448 1476 ? SN 14:09 0:04 /bin/bash /usr/local/sbin/rpimonitor-helper.sh /var/run/rpimonitor-helper.pid root 731 0.0 3.3 49600 8228 ? SNs 14:09 0:00 /usr/bin/perl /usr/bin/rpimonitord -b /var/run/rpimonitord.pid tk 738 0.0 3.3 49872 8296 ? SN 14:09 0:00 /usr/bin/perl /usr/bin/rpimonitord -b /var/run/rpimonitord.pid root 739 1.0 3.4 49732 8564 ? SN 14:09 0:13 /usr/bin/perl /usr/bin/rpimonitord -b /var/run/rpimonitord.pid Link to comment Share on other sites More sharing options...
Recommended Posts