Open Seirdy opened 2 years ago
Hi Rohan, thanks a lot for the recommendation! I thought about it too, but didn't add it to the basic summary, because to calculate the median, we will have to store all the ping results, which will make the memory keep growing, so it will impact cases such as long running continuous ping. So, currently, in basic summary and logs, we don't store any ping results but only measure running statistics, unless we explicitly enables advanced graphs such as latency scatter.
To avoid the outliers, I added -b 0.0
to enable latency buckets to show the latency distributions. It might help you in the short term.
And I am wondering - how about we add a new command line opt for it? Say, --show-median with --smd as short alias.
Here is an example of latency bucket. Hope it helps!
> rnp.exe 8.8.8.8:443 -b 0.0
Rnp - r12f (r12f.com, github.com/r12f) - A simple layer 4 ping tool for cloud.
Start testing TCP 8.8.8.8:443:
Reaching TCP 8.8.8.8:443 from 192.168.0.151:10112 succeeded: RTT=12.29ms
Reaching TCP 8.8.8.8:443 from 192.168.0.151:10113 succeeded: RTT=13.83ms
Reaching TCP 8.8.8.8:443 from 192.168.0.151:10114 succeeded: RTT=12.60ms
Reaching TCP 8.8.8.8:443 from 192.168.0.151:10115 succeeded: RTT=12.80ms
=== Connect statistics for TCP 8.8.8.8:443 ===
- Connects: Sent = 4, Succeeded = 4, Failed = 0 (0.00%).
- Round trip time: Minimum = 12.29ms, Maximum = 13.83ms, Average = 12.88ms.
=== Latency buckets (in milliseconds) ===
Latency Range | Count
----------------+------------
< 0.10ms | 0
< 0.50ms | 0
< 1.00ms | 0
< 5.00ms | 0
< 10.00ms | 0
< 30.00ms | 4
< 50.00ms | 0
< 100.00ms | 0
< 300.00ms | 0
< 500.00ms | 0
>= 500.00ms | 0
Timed Out | 0
Failed | 0
----------------+------------
Total | 4
On Sun, Sep 11, 2022 at 11:37:56PM -0700, Riff wrote:
So I am wondering - how about we add a new command line opt for it? Say, --show-median with --smd as short alias.
If we have a CLI flag to store all data, that could also be useful for percentiles and histograms. But the first priority should probably be parity with existing "ping" utilities. I'd be fine with the extra option.
-- Seirdy (https://seirdy.one)
Hi Rohan, have you tried the -b 0.0
parameter I listed above? It will do what you are asking - store all the data and show the histograms in the end.
also, although i do agree it might be nice to have, but i don't think it is anything close to "parity to existing ping utilities" or anything urgent. I have tried 4 different most frequently used pings on both linux and windows, but none of them provides median as part of result summaries. please feel free to check the details below. And if you are somehow blocked by this, please feel free to give the -b parameter a try. it is flexible and can provides much better insight on the latency distributions :)
ping on windows:
> ping 8.8.8.8
Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=3ms TTL=117
Reply from 8.8.8.8: bytes=32 time=3ms TTL=117
Reply from 8.8.8.8: bytes=32 time=3ms TTL=117
Reply from 8.8.8.8: bytes=32 time=3ms TTL=117
Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 3ms, Maximum = 3ms, Average = 3ms
psping on windows:
> psping 8.8.8.8:443
PsPing v2.10 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2016 Mark Russinovich
Sysinternals - www.sysinternals.com
TCP connect to 8.8.8.8:443:
5 iterations (warmup 1) ping test:
Connecting to 8.8.8.8:443 (warmup): from 127.0.0.1:51105: 0.22ms
Connecting to 8.8.8.8:443: from 127.0.0.1:51107: 0.21ms
Connecting to 8.8.8.8:443: from 127.0.0.1:51109: 0.17ms
Connecting to 8.8.8.8:443: from 127.0.0.1:51111: 0.20ms
Connecting to 8.8.8.8:443: from 127.0.0.1:51114: 0.28ms
TCP connect statistics for 8.8.8.8:443:
Sent = 4, Received = 4, Lost = 0 (0% loss),
Minimum = 0.17ms, Maximum = 0.28ms, Average = 0.21ms
ping on linux:
$ ping 8.8.8.8 -c 4
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=4.02 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=116 time=3.29 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=116 time=3.40 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=116 time=3.31 ms
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 3.291/3.502/4.019/0.300 ms
hping:
$ sudo hping 8.8.8.8 -c 4 -1
HPING 8.8.8.8 (eth0 8.8.8.8): icmp mode set, 28 headers + 0 data bytes
len=28 ip=8.8.8.8 ttl=116 id=0 icmp_seq=0 rtt=19.9 ms
len=28 ip=8.8.8.8 ttl=116 id=0 icmp_seq=1 rtt=19.7 ms
len=28 ip=8.8.8.8 ttl=116 id=0 icmp_seq=2 rtt=19.6 ms
len=28 ip=8.8.8.8 ttl=116 id=0 icmp_seq=3 rtt=19.5 ms
--- 8.8.8.8 hping statistic ---
4 packets tramitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 19.5/19.7/19.9 ms
Standard ping utilities typically report median RTTs as well as averages. This is a simple way to report a real representative time that isn't an outlier. Having this feature in rnp would be really helpful.