Closed mrbesen closed 1 year ago
Sounds linke a bug, PRs welcome ;)
Unable to reproduce, it works with even much larger numbers. The counting, however, may be incorrect depending on what you expect it to be: The Second number is globalrx
, i.e. the number of responses and not the number of pings sent.
The three numbers you underlined are: globallost, globalrx, globallost*100.0f/(globalrx+globallost)
Maybe we should make the second globallost+globalrx i.e. roughly the number of sent packets?
(Ping some unused local IP to see that the first number increases and the second stays 0. Confusing, I agree.)
Yes, i think that is the real "problem".
I supose we should make it <globallost>:<globalrx>
or <globallost>/<globalrx+globallost>
.
I think the second one is the most intuitive.
My vote: <globallost>/<globalrx+globallost>
(The a:b format is common in sports and bets but the parts/total seems more intuitive in a technical environment to me. Especially since it is tagged "historical loss" it makes sense to give the value in relation to the total.)
Lets give @cnlohr a few days in case he had a different idea when first designing this :thinking:
I'm good with that!
(I'm good with either proposal)
Fixed. Thanks for bringing it up @mrbesen !
The only slightly confusing thing left now is that we count a ping as lost (and also count it towards total) only after a timeout of about 4s is reached. That makes somewhat sense and leads to a more stable lost percentage display but it may not be understandable at first. A successful ping on the other hand is counted as soon as it is received.
Not a bit issue imo but I just wanted to document it here.
I have used cnping multiple days without a restart (ping interval of 5s). After some time, some numbers are not displayed correctly anymore.
It looks to me like the last few places of that number are missing. The left number counts up, the right one does not change.