Closed edgar-bonet closed 7 months ago
@hartwork: Replace sleep 0.25
with sleep 2
. You will see that both master an this PR's branch compute the same thing: a rate of roughly 2400 hits/s.
@hartwork: Replace
sleep 0.25
withsleep 2
.
@edgar-bonet … because the old code uses a timer with seconds resolution and therefore 0.25 is too fast for it then I suppose, interesting!
I guess then maybe this pull request is just doing the right thing? :smiley:
The variable naming x
and y
seem a bit unfortunate given that (1) both seem to be y coordinates and (2) the application uses x and y already for 2-dimensional coordinates in ncurses space. If you could pick a different pair of names, I'd likely be all for the new ones. What do you think?
@hartwork wrote:
The variable naming
x
andy
seem a bit unfortunate
Indeed it is. I replaced them with v1
and v2
, which are more consistent with the current naming. I also added const
qualifiers as you suggested. Squashed and force-pushed.
interesting, so basically if samples for rate calculator are sub second interval the data will be lost? I would love to fix this, but I will need to do a lot more testing, typically with network equipment/snmp where I use it the most
also note that torture.c was never designed for rate testing, it would be cool if you could add it as well, maybe make the sleep/interval an arg/flag and option for rate (-r) ?
ideally torture -r
should be able to generate a similar wave plot like without -r
by manipulating rate (higher/lower)
@tenox7 wrote:
if samples for rate calculator are sub second interval the data will be lost?
Not exactly. Each number received on the input adds one bar to the plot, so no data is lost. The issue is that, in master, the values are incorrect. If the interval is large, the rates displayed are real rates (i.e. time derivatives), in counts per second. If the interval becomes smaller than one second, then ttyplot
“rounds” it up to one full second, which results in overestimated rates.
The issue also impacts intervals that are longer (but not much longer) than one second. For example, the command
for n in $(seq 1 10 1000); do echo $n; sleep 1.5; done
creates a counter that increments by ten units every 1.5 seconds. This is a rate of 6.7 counts per second. Piping this to ttyplot
in master shows a rate that alternates between 5 and 10. With this pull request, ttyplot
shows a very steady rate of 6.7.
torture.c was never designed for rate testing, it would be cool if you could add it as well [...]
I would gladly do so. Within this PR or in a follow-up one?
I would gladly do so. Within this PR or in a follow-up one?
My vote for merging to master
what we have here and then doing a follow-up. Fewer bits in flight, baby steps, shorter-lived branches. Clear vote for a merge from my side.
The program torture.c outputs a waveform of amplitude 5 and period 0.72 s. Its peak derivative is therefore expected to be
However,
shows a waveform that peaks at about 0.5, which is off by two orders of magnitude. The reason is that data points arrive every 10 ms, and ttyplot “rounds” this value to a full second, effectively underestimating the rate by a factor 100.
This pull request fixes this behavior by handling time with microsecond resolution. It also moves the computation of rates to its own function for better code clarity.