WarHawk_AVG Posted July 17, 2018 Posted July 17, 2018 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 1
chrisf Posted July 17, 2018 Posted July 17, 2018 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 1
tkaiser Posted July 17, 2018 Posted July 17, 2018 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. 1
Tido Posted July 17, 2018 Posted July 17, 2018 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 Posted July 17, 2018 Posted July 17, 2018 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) 1
WarHawk_AVG Posted July 17, 2018 Author Posted July 17, 2018 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 Posted July 17, 2018 Posted July 17, 2018 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... 2
Recommended Posts