Closed altf4 closed 9 years ago
Yeah my use case for this tool is "why is this sucking? Oh, because the internet just died. Do I need to reconnect or something?" The graph is there so you don't feel like you've gotta keep an eye on it second-by-second. But as you mention, an average doesn't really speak to quality issues. You could treat E as whatever the TTL is (1000 ms?) but that's not as useful as "half our packets in the last minute have totally failed."
Right now my most desired features are cross-compatibility with non-Ubuntu, and an improved graph (using braille characters results in low information density but I couldn't find a better option easily) On Jan 5, 2014 12:39 AM, "AltF4" notifications@github.com wrote:
I started writing a feature to toggle the display of a running average of the pings in the current log. However, it wasn't immediately clear to me how error pings should be handled.
Simply ignoring them doesn't feel accurate, as it would make the average higher than it should be, and probably defeat the purpose of displaying it. (Keeping an eye on your network quality)
But how do you numerically account for the missing ping in an average?
Perhaps a running average feature just doesn't make sense in this context.
— Reply to this email directly or view it on GitHubhttps://github.com/zyphlar/pinger/issues/3 .
@altf4 I just implemented a simple running average; it's a simple average so failures count as -1 which is wrong, but the number is still somewhat useful for now.
I started writing a feature to toggle the display of a running average of the pings in the current log. However, it wasn't immediately clear to me how error pings should be handled.
Simply ignoring them doesn't feel accurate, as it would make the average higher than it should be, and probably defeat the purpose of displaying it. (Keeping an eye on your network quality)
But how do you numerically account for the missing ping in an average?
Perhaps a running average feature just doesn't make sense in this context.