gotop

[WarHawk_AVG]

Possible addition for stock Armbian builds...adds quite a bit to the terminal based graphical status

 

https://github.com/cjbassi/gotop

 

Spoiler

https://github.com/cjbassi/gotop/raw/master/assets/demo.gif

 

[chrisf]

You've bunged up the link somehow, there's a unicode byte order marker between i and / in cjbassi/gotop

If you copy/paste into a url bar you'll get a 404 and scratch your head because it looks identical to a url with %EF%BB%BF in it

 

[WarHawk_AVG]

corrected...sorry about that

 

[tkaiser]

1 hour ago, WarHawk_AVG said:

adds quite a bit to the terminal based graphical status

 

Fancy graphics that are totally useless (even on x86). On all the ARM boards and in the meantime everywhere on x86 as well the hardware + kernel implement cpufreq scaling. On some boards we allow min cpufreq to be as low as 240 MHz while under load when no throttling occurs cpufreq can climb up to 1200 MHz.

 

Graphs that do not visualize this important fact are... 100% meaningless.

 

An SBC with 20% CPU utilization at 1200 MHz is way more busy than the same SBC with 50% CPU utilization at 240 MHz while the fancy graph will show exactly the opposite.

 

@lex' htop is better but if you really want to get a clue what's going on in Armbian you need to open a few windows and run htop, 'iostat 5' and 'armbianmonitor -m' in parallel (though with most recent armbianmonitor version you don't need iostat any more since armbianmonitor is able to display where 'average load' originates from -- on SBC the amount of %iowait percentage is crucial)

 

BTW: the concept of 'average load' especially on Linux and especially on SBC running off horribly slow storage is mostly misunderstood.

[Tido]

50 minutes ago, tkaiser said:

Fancy graphics that are totally useless (even on x86). On all the ARM boards and in the meantime everywhere on x86 as well the hardware + kernel implement cpufreq scaling. On some boards we allow min cpufreq to be as low as 240 MHz while under load when no throttling occurs cpufreq can climb up to 1200 MHz.

This is indeed an interesting observation, however, how do you know that it takes:
  240MHz for 100%
1200MHz for 100%
if it does only look at the tact, in regard to the maximum allowed (1200) gotop looks fine.

If it does always adjust to the governor - then you are right.

 

[tkaiser]

48 minutes ago, Tido said:

If it does always adjust to the governor - then you are right

 

No idea what you're talking about. The cpufreq governor 'just works' (or not as expected -- see this thread). The gotop tool has no clue at which frequency the CPU cores are running so it simply graphs numbers without meaning.

 

Just tried it out on an idle Lime2. First try with our default cpufreq settings: the tool is that demanding that it already influences the system's behaviour. The Lime2 usually idles stable at 528 MHz but wenn running gotop the governor often decides to enter higher cpufreq OPP since 'too much demand'. So this is just another example of 'monitoring gone wrong' since monitoring negatively affects the system's behaviour. You watch stuff that wouldn't happen if you were not watching.

 

To test how bad the graphing is it as easy as using a fixed cpufreq. I switched to performance governor and set max cpufreq to 912 MHz, then started gotop, then waited few seconds and adjusted cpufreq to 144 MHz just to switch back to 912 MHz after some more seconds:

The system was idle all the time, it's just gotop being both pretty heavy wrt CPU usage and not caring about something that happens everywhere around since almost a decade: cpufreq scaling.

 

BTW: on ARM big.LITTLE systems gotop's output will be even more misleading.

 

I know that people will love this utility since people love colorful graphics and always prefer (meaningless) data over information. Users might have fun staring at these misleading graphs but at least for developers this tool is of no use at all (so wrong forum -- most probably the 'eye candy and fancy stuff' subforum would be better suited , SCNR)

[WarHawk_AVG]

Yeah, guess without cpu scaling taken into account...it's just glitz and pointless
It does work well on my Laptop running Linux Lite thought...so for something like that I guess it's ok

 

Was hopeful it would be useful...turns out it's just more useless eye candy

 

Thanks for the report and testing...fooey

 

[tkaiser]

50 minutes ago, WarHawk_AVG said:

turns out it's just more useless eye candy

 

Actually it's nice. It simply suffers from what almost all other tools trying to display 'CPU utilization' in some way or the other also suffer from: ignoring reality.

 

With cpufreq scaling 'CPU utilization' alone doesn't tell that much any more especially on systems where all this stuff happens very dynamically (e.g. TurboBoost on x86 where CPU cores clock from 1.2 GHz to 2.2 GHz when just one core is busy, but as soon as a second core processes stuff immediately downclock to 1.8 GHz and stuff like that. Same situation with ARM especially with big.LITTLE and/or on boards where a cheating firmware controls what's happening and the kernel not even has any clue at which clockspeeds the CPU cores are running --> fortunately only applies to Raspberry Pi and Amlogic SBC)

 

I thought several times about an utility both being correct and providing nice looking output. But apart from enhancing RPi-Monitor with templates for some ARM SoC families our armbianmonitor approach is all we came up with. Ugly but at least providing real information and not illusions:

 

root@rock64:~# armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.
10:25:43: 1392MHz  0.39   9%   2%   3%   0%   2%   0% 41.4°C  0/6
10:25:49:  600MHz  0.36   0%   0%   0%   0%   0%   0% 40.9°C  0/6
10:25:54: 1392MHz  0.41   2%   0%   1%   0%   0%   0% 45.5°C  0/6
10:25:59: 1392MHz  0.46  37%   9%  16%   0%  10%   0% 48.2°C  0/6
10:26:04: 1392MHz  0.50  29%   8%  10%   0%  11%   0% 48.2°C  0/6
10:26:09: 1392MHz  0.70  36%   8%  18%   0%   9%   0% 45.0°C  0/6
10:26:14: 1392MHz  1.37  40%   1%   0%   0%  38%   0% 44.1°C  0/6
10:26:19: 1392MHz  1.34  27%   3%  17%   0%   6%   0% 50.0°C  0/6
10:26:24: 1392MHz  1.31  25%   0%  24%   0%   0%   0% 51.7°C  0/6
10:26:29: 1392MHz  1.28  25%   0%  25%   0%   0%   0% 51.7°C  0/6
10:26:34: 1392MHz  1.26  26%   3%  22%   0%   0%   0% 51.2°C  0/6
10:26:39: 1392MHz  1.64  25%   6%  19%   0%   0%   0% 49.5°C  0/6
10:26:44:  600MHz  2.07   2%   2%   0%   0%   0%   0% 42.7°C  0/6
10:26:49: 1392MHz  1.98  24%   0%   0%   0%  22%   0% 47.7°C  0/6
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.
10:26:55: 1392MHz  1.91  24%   0%   0%   0%  24%   0% 46.4°C  0/6
10:27:00: 1392MHz  1.83  22%   1%  10%   0%  10%   0% 46.4°C  0/6
10:27:05:  600MHz  1.69   0%   0%   0%   0%   0%   0% 44.1°C  0/6
10:27:10:  600MHz  1.55   2%   0%   1%   0%   0%   0% 44.1°C  0/6^C

 

This is a Rock64 running off a really crappy 4GB SD card (I got a bunch of them recently when replacing them with SanDisk Ultra A1 at a customer) doing an 'apt update'. We see cpufreq increasing, average load increasing and even overall %cpu utilization increasing. But by looking at %io we see that the whole system is often stuck in IO simply because the SD card performs horribly low when it's about random IO. See the '10:26:14' entry: 40% CPU that are in reality only waiting for the crappy SD card finishing its work.

 

That's the problem with 'CPU monitoring' on Linux in general and especially on SBC where 'crappy storage' is more rule than exception. When looking at load or CPU utilization it's all the time misleading as soon as slow performing storage is involved. Since 'Linux waiting for IO' counts as 'CPU busy / increased load'.

 

That's why I unfortunately can only recommend our ugly armbianmonitor to really get a clue what's going on...