tmux-plugins / tmux-cpu

Plug and play cpu percentage and icon indicator for Tmux.
MIT License
426 stars 65 forks source link

Use current cpu percentage #20

Closed qikaigu closed 5 years ago

qikaigu commented 6 years ago

Close #19

A more accurate cpu percentage computation in case that iostat and sar are not available.

ctjhoa commented 6 years ago

Here is what i've got in load using your computation:

$ top -bn 1 | awk 'NR>7{s+=$9} END {print s}'
942

Can you explain your computation a little bit I'm not an awk expert?

As mentionned in the README, you must use iostat or sar to get accurate result. https://github.com/tmux-plugins/tmux-cpu#optional-requirement-linux-bsd-osx

qikaigu commented 6 years ago

I'm using top with batch mode -b and a single iteration -n 1 to get a list of processes or threads currently being managed by the Linux kernel. The first 7 lines of the command top -bn 1 are system summary information and a header for the list of processes or threads. This is not useful in our case so I use awk 'NR>7' to get rid of it. The 9th column in the list corresponds to the CPU usage. The sum of each process/thread CPU usage is what we want.

You got 942 as the computation result. This may be because you use a CPU having number of threads higher than 9. The CPU usage got from top is per thread. If you divide the load by cpus, it should return the global CPU usage. If your CPU thread number is less or equal to 9, then there should be a problem with my computation.

casperdcl commented 6 years ago

is there a citation somewhere showing top to be more accurate than ps?

ctjhoa commented 6 years ago

@qikaigu Sorry for the late reply. I've done some test with the stress command and the ps aux version is pretty accurate. You said:

I found that the CPU percentage for Linux seems to be the average CPU percentage since boot

I don't think it's an average CPU usage can you give more detail on this.

BTW, your top version is working too but I will not accept this if I do not understand the reason behind it. Thanks for your patience

qikaigu commented 5 years ago

Sorry for the delayed response. @casperdcl @ctjhoa I'll paste the official manual for ps and top.

For ps:

%cpu The CPU utilization of the process; this is a decaying average over up to a minute of previous (real) time. Because the time base over which this is computed varies (some processes may be very young), it is possible for the sum of all %cpu fields to exceed 100%.

For top:

%CPU -- CPU Usage The task's share of the elapsed CPU time since the last screen update, expressed as a percentage of total CPU time.

It says that ps calculate the CPU utilization in a way of decaying average over up to a minute. If a real CPU utilization instantly drops from 100% to 0% and stays at 0%, the result shown by ps would have to wait for a minute to be accurate. In contrast, top doesn't calculate the CPU utilization in the same manner. This explains why I observed the average CPU percentage by using ps.

From what I observed, top reflects the real CPU utilization more accurately than ps.

Hope that makes sense. :)

ctjhoa commented 5 years ago

Hum, on archlinux ps man is different:

%CPU cpu utilization of the process in "##.#" format. Currently, it is the CPU time used divided by the time the process has been running (cputime/realtime ratio), expressed as a percentage. It will not add up to 100% unless you are lucky. (alias pcpu).

Similar to this man page: http://man7.org/linux/man-pages/man1/ps.1.html

Looks like you're on BSD right ? https://www.freebsd.org/cgi/man.cgi?ps(1)

ctjhoa commented 5 years ago

Ok so I noticed another difference between Linux & BSD. According to: https://linux.die.net/man/1/top https://www.freebsd.org/cgi/man.cgi?top(1)

BSD top do not have the same -n option:

 -n        Use non-interactive mode.  This is identical to batch mode.

So your top alternative should not work on a BSD environment.

qikaigu commented 5 years ago

Actually, I copied the manual of ps from an OSX without noticing it. The test was on Linux (Ubuntu 16.04 LTS). Sorry about that. I don't know what has been changed but I can't reproduce the inaccuracy as I did in 2017. I'll close the PR and issue.