> The “pipe” number is the maximum number of echo request packets that have been under way at one time, without having been answered by an echo reply packet (but did get answered in the end).
I followed the example from my MacBookPro (Big Sur 11.7.09) using terminal. It would not allow me to spec an interval under 0.1.
$ ping -c 4 -i 0.1 218.101.61.162
PING 218.101.61.162 (218.101.61.162): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
64 bytes from 218.101.61.162: icmp_seq=0 ttl=54 time=212.910 ms
64 bytes from 218.101.61.162: icmp_seq=1 ttl=54 time=201.219 ms
64 bytes from 218.101.61.162: icmp_seq=2 ttl=54 time=204.627 ms
64 bytes from 218.101.61.162: icmp_seq=3 ttl=54 time=203.737 ms
--- 218.101.61.162 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 201.219/205.623/212.910/4.389 ms
$ ping -c 4 -i 0.09 218.101.61.162
ping: -i interval too short: Operation not permitted
t's a limitation imposed by the ping programme itself, it'll refuse to use very short intervals if you're not root. This is documented in the man page. Or, use the source, Luke:
case 'i': /* wait between sending packets */
t = strtod(optarg, &ep) * 1000.0;
if (*ep || ep == optarg || t > (double)INT_MAX)
errx(EX_USAGE, "invalid timing interval: `%s'",
optarg);
options |= F_INTERVAL;
interval = (int)t;
if (uid && interval < 100) {
errno = EPERM;
err(EX_NOPERM, "-i interval too short");
}
break;
And if you keep looking, Apple's version of ping keeps track of the number of sent and received probes, but does not keep track of the largest difference between the sequence nubmer of sent and received probes, so it will not print the same "pipe" value as the iputils version of ping (ie. the version you typically get in Linux).
I believe you need escalated privileges (I don’t know which capability, specifically) for intervals under a certain point. The author was running as root.
Yup! The details of Linux networking API are often surprising.
I think if it's possible to change the ping algo to reduce the potential for wall clock change affecting the measurement.
For example, instead of using SO_TIMESTAMP to measure wall clock diffed with the send time, maybe it's possible to grab the wall clock just before recv() and use wall clock to measure the event-loop time only (which is way shorter than the ping rtt).
$ dpkg -S /bin/ping
iputils-ping: /bin/ping
$ grep 'downloaded from' /usr/share/doc/iputils-ping/copyright
It was downloaded from https://github.com/iputils/iputils
$ git clone https://github.com/iputils/iputils
...
$ cd iputils/ping
Then a bit of looking around shows that in acknowledge() (an inline helper defined in ping.h), pipesize records the largest difference between the sequence number of the (last) outbound probe and than the sequence number of the inbound probe we're receiving. That function is called from gather_statistics() (for the happy path) and in a couple of other locations when receiving an ICMP error.
$ pacman -Qqo $(which ping) # -Qqo is --query --quiet --own
iputils
$ asp export iputils && cd iputils
$ # see PKGBUILD for URLs, or if you just want to have a look:
$ gpg --import keys/pgp/*.asc # or pass --skippgpcheck to makepkg below
$ makepkg -od && cd src # -od is --nobuild --nodeps
for the second step usually works, although I don’t know how to figure out the package name reliably (ls -l will usually point you in the right direction, but for ping it just gives you the wrapper).
