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?

 

 

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

 

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.

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.

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