The Stress Terminal UI (s-tui) is a Pretty CPU and Temperature Monitoring Terminal App

While it’s possible to do monitoring with tools like RPI-Monitor on headless or remote systems, top and htop are likely the commonly used tools to monitor CPU and process usage in the terminal. There’s now a new and different option with the Stress Terminal UI that display pretty charts for frequency, CPU usage, and temperature in the terminal, and as its name implies it can also stress the system.

I’ve first installed it in my main computer running Ubuntu 16.04.2 as follows:


and then just started it


It took the screenshot above after enabling stress operation for a few seconds, and while frequency and CPU utilization in percent are updated properly, temperature is not, at least on my system. I had to enable “Smooth Graph” option to see any changes in the first two charts. I tried to run the app again with sudo, but still no temperature update, and that’s because the program is confused since I have two “temp1” values in my machine, one for “it8720” that will always show a constant temperature (45 °C) and one for “AMD CPU” that will vary depending on the load.

Click to Enlarge

A good solution would have to have an option to select the sensor, but there’s no such option for s-tui right now:


I switched to an ARM platform, namely NanoPi NEO board:


So it does not work with Python 3, and requires Python 2.7. Let’s give it another try:


I could install it and run it, but only CPU and temperature charts would be drawn.

The temperature sensor may have not been detected due to the following error:


msr appears to be be something called “model-specific registers”, and only used for x86 CPU, so ARM detection did not work or was not performed here. The developers did test the program successfully with a Raspberry Pi 3 board however. He’s also aware of issues with temperature sensors:

If the temperature does not show up, your sensor might not be supported. Try opening an issue on github and we can look into it

So overall, it’s still work in progress. Support for showing info for multiple cores would be nice, but probably only suitable in a full screen terminal.

Via It’s FOSS

12
Leave a Reply

avatar
12 Comment threads
0 Thread replies
4 Followers
 
Most reacted comment
Hottest comment thread
5 Comment authors
AlexcnxsoftSandertkaiserRK Recent comment authors
  Subscribe  
newest oldest most voted
Notify of
RK
Guest
RK

Pretty. If it had a toggle-able top menu (like htop) it would get a permanent Ctrl+Alt+1 virtual console on my servers and workstations 🙂

tkaiser
Guest
tkaiser

I tried it on one of the slowest servers we use (Lime2 with dual-core A20 limited to 960 MHz). I get the same

But temperatures were reported correctly. Also the tool is lightweight enough to not change system behaviour (that’s a huge problem with most usual monitoring solutions when running on embedded devices: the daemons collecting data being too aggressive and by starting to monitor the whole system behaviour changes… eg. CPU cores now running constantly at the upper clockspeed).

Me monitoring the monitoring (s-tui picking the wrong one: PMIC instead of SoC) 😉 and searching for available ‘sensors’:

Alex
Guest
Alex

Thank you for the input. We are hard at work addressing the issues you have mentioned

tkaiser
Guest
tkaiser

@Alex
In case you want to support a couple of dev boards properly please be aware that thermal readouts also depend on kernel version (for many SBC more than one kernel variant exists, eg. the very popular Orange Pi can run a smelly 3.4 kernel but also latest and greatest mainline — sysfs node to readout temperature is the same with both kernels but with legacy you get degrees and with mainline kernel millidegrees instead).

In Armbian wrt CPU/SoC temperature it’s basically this to get the proper SoC temperature sysfs node and that to interpret the value properly (tested on +50 SBC with up to 3 kernel variants per board).

In the last link starting at line 268 you could also see how to deal properly with big.LITTLE boards (big and little cores can clock at different clockspeeds, but on all devices we know it’s a single cpufreq per cluster, so it’s only needed to check cpu0 and cpu4 but since in the meantime there are also SoCs using 2 big and 4 little cores — eg RK3399 — it would be cpu0/cpu2 there. So checking /proc/cpuinfo at start seems to become mandatory in the future to properly display clockspeeds of different ARM CPU core clusters)

Sander
Guest
Sander

I get “IOError: [Errno 61] No data available” … so I created an issue on Github …

Alex
Guest
Alex

We have just released a new version. You can now select a temperature sensor manually, as was suggested in this post. Hopefully in the future all the sensors will be availableh in the TUI

Alex
Guest
Alex

@cnxsoft
Glad to hear it worked out for you.
The power read is currently only available on >= Intel 2nd Gen CPUs. If there is a way to get the this data for AMD/ARM systems, we would like to hear suggestions/receive pull requests.

I believe the power sensor that shows up is of your graphics card and not of the CPU.

Alex
Guest
Alex

I believe the power sensor that shows up is of your graphics card and not of the CPU.

If I’m wrong, it should be possible to integrate it in the next version

Alex
Guest
Alex

@cnxsoft
Looks promising. The only problem now is to get access to an AMD system.

Alex
Guest
Alex

So it does not work with Python 3, and requires Python 2.7. Let’s give it another try:

Newest version supports python3