billybangleballs Posted March 5, 2017 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?
tkaiser Posted March 5, 2017 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
billybangleballs Posted March 5, 2017 Author 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.
TonyMac32 Posted March 7, 2017 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
tkaiser Posted March 12, 2017 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
Recommended Posts