Add a --tick-interval or similar option.
jimeh opened this issue · 4 comments
Currently each time rainbarf is executed, it ticks the graph over by one character. In Tmux this happens every 15 seconds by default, giving a nice long historical CPU graph. However I personally have Tmux update the status every second, giving me 38 seconds worth of CPU history.
Hence I'd like to suggest an option that sets how many times rainbarf needs to run before the graph is ticked over once. By default it would obviously be set to 1.
I do realize it would make things a bit more complex. For example if the tick-interval option is set to 15, the each block in the graph should probably be an average CPU usage from the past 15 runs, rather than what it is at the moment rainbarf runs.
This could be easily implemented with skipping: rainbarf --skip 15 would only rotate the history if the last write to the history file was at least 15 seconds ago. Although, weird behaviour is expected when tmux refresh is, say, 11 and skip is, say, 23. What do you think?
Yes, simply basing it around the number of seconds since last change to the history file is definitely a nice and simple solution for what I'm after :)
Of course it wouldn't be as accurate as if it kept measuring CPU usage on every run, and updated the latest block with the average for the duration of the current block. As you'd end up with a historical graph of what the CPU usage was during narrow points in time separated by 15 seconds.
However the implementation simplicity of --skip probably makes the less accurate CPU graph acceptable in my opinion :)
But yes, the timing could get weird if you don't match the tmux interval with the --skip setting. And thinking about it, I would probably knock off 0.5 seconds from whatever is specified. For example, if --skip is set to 15, and Tmux updates every 15 seconds, I believe there's a slight risk that it could be 14.999 seconds since rainbarf last ran as far as it's concerned. Hence treating 15 as 14.5 would solve such issues. That is assuming timing is available down to milliseconds, rather than just whole seconds of course.
Implemented the --skip option in 13e145d, could you test it please? I guess that the sub-second precision is OS-dependant. Unfortunately, on both Linux and Mac OS X, it seems to be precise up to seconds.
--skip seems to work like a charm 👍 😄