-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
status-interval not respected #15
Comments
I'm not sure if this is something related to |
As you can see get cpu percentage is very slow because you can only get CPU from a time frame of 1 second (thanks to |
In theory, it should be something like this:
|
In fact, replacing With the battery plugin it appears not to have this issue, at least using EDIT: just to clarify, I'm on linux. |
From linux
so I cannot use the first report |
Same from BSD
|
Right... So, another way has to be found :) |
FYI with the iostat in |
I have this issue as well, and I think it's related to tmux/tmux#797 (comment). Maybe, as a way to fix this, the |
previously we invoked vmstat and parsed its output to report on supposedly 'recent' CPU consumption. however, as invoked, vmstat outputs cumulative-since-boot CPU numbers, as that's all the kernel interface supplies. having vmstat wait a few seconds to report last-few-seconds numbers is possible, but is not recommended (see tmux/tmux#797 (comment) ) and results in status line updates at rapid and irregular intervals (see tmux-plugins/tmux-cpu#15 ). this is distracting, and also makes tmux create high load on an ancient raspi. so instead, we kludge using tmux as a sort of background job manager, launching vmstat on a high-numbered window and parsing its output into a file underneath our systemd-created session tmpfs, from which the tmux status line reads it. vmstat is used over iostat/mpstat/etc as it should be always available (at least on Debian systems where procps is Priority: important).
Is this still an issue in the latest bits, and what is the current recommended workaround (OP was a few years ago). |
@lonix1 iostat versions are very different across OSes and even depending on the version used. If you really care about the update frequency of your status bar, an alternative could be to add an option to customize the command used to compute CPU. |
@ctjhoa Since you know much more about this than I do, what approach do you take/recommend? (I'm on latest ubuntu BTW). |
@lonix1 What I mean is, if we cannot guess what |
Is this still an issue? To be clear, this should not be the case:
Seems like it was an upstream bug but isn't a thing any more? My local tests show |
While testing this, I think I've found an upstream problem (with set -g status-right "%H:%M:%S #(sleep 1)"
set -g status-interval 5 will ignore |
I have another solution. I know this is ugly because
But it's faster than running the iostat command directly and it can get the cpu percentage with longer interval (ex: 5s) my cronjob my tmux.conf modified cpu_percentage.sh
|
The code assumes that the status bar will only be updated every status-interval seconds In practice status-interval is a maximum value, not a minimum value. So if the status bar is actually updated every second even though the configuration is for 5 seconds all of the calculations are off and the bitrate will be calculated as a fifth of the real rate. See tmux-plugins/tmux-cpu#15 for a similar issue with a different plugin, except that here it is much worse because it actually leads to a WRONG RESULT and not just a faster update. This commit implements @BrainMaestro 's suggestion from that thread.
So, after installing the plugin I noticed that my status bar was updated too frequently. Apparently, the presence of tmux-cpu influences the update and
status-interval
is ignored.For example, if I set
I can see the seconds updated every 5 seconds. On the other hand, if I add the tmux_cpu plugin:
I will see the seconds and the CPU percentage updated almost every second, disregarding the value of status-interval. I think status-interval should be taken into account, and I see this behaviour as buggy.
I can help with the debug, but not being familiar with tmux-plugins in any way I don't know where to start.
The text was updated successfully, but these errors were encountered: