Bug #6210


ping can misreport ICMP latency

Added by Robert Mustacchi almost 6 years ago. Updated almost 6 years ago.

Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:


ping(1M) by default attempts to perform a DNS reverse lookup for a given IP address. When this succeeds, it's of some value. However, when it fails, things go off the rails. First off, we end up delaying the reporting of packets. The much more criminal thing is that we end up including the failed DNS resolution time in the time the ping took!

This often causes something to look like:

[root@36e435c7-266c-cf78-d972-a39e33a2c7c2 ~]# ping -s 
PING 56 data bytes 
64 bytes from icmp_seq=0. time=63.842 ms 
64 bytes from icmp_seq=1. time=22008.527 ms 
64 bytes from icmp_seq=2. time=21008.593 ms 
64 bytes from icmp_seq=3. time=20008.640 ms 
64 bytes from icmp_seq=4. time=19008.682 ms 
64 bytes from icmp_seq=5. time=18008.748 ms 
64 bytes from icmp_seq=6. time=17008.776 ms 
64 bytes from icmp_seq=7. time=16008.845 ms 
64 bytes from icmp_seq=8. time=15008.875 ms 
64 bytes from icmp_seq=9. time=14008.931 ms 
64 bytes from icmp_seq=10. time=13008.967 ms 
64 bytes from icmp_seq=11. time=12009.047 ms 
64 bytes from icmp_seq=12. time=11009.086 ms 
64 bytes from icmp_seq=13. time=10009.111 ms 
64 bytes from icmp_seq=14. time=9009.158 ms 
64 bytes from icmp_seq=15. time=8009.203 ms 
64 bytes from icmp_seq=16. time=7009.286 ms 
64 bytes from icmp_seq=17. time=6009.334 ms 
64 bytes from icmp_seq=18. time=5009.374 ms 
64 bytes from icmp_seq=19. time=4009.424 ms 
64 bytes from icmp_seq=20. time=3009.451 ms 
64 bytes from icmp_seq=21. time=2009.517 ms 
64 bytes from icmp_seq=22. time=1009.545 ms 
64 bytes from icmp_seq=23. time=115.486 ms 
64 bytes from icmp_seq=24. time=20.667 ms 
64 bytes from icmp_seq=25. time=44.564 ms 
64 bytes from icmp_seq=26. time=91.477 ms

Note the long series of delays in terms of seconds until about 20 seconds have elapsed and we've timed out all of the DNS resolutions.

I'm not 100% sure on what would be the best behavior here. It feels to me like with an ICMP ping, the most important thing is to show the user the behavior that the network is functioning from an ICMP perspective, even if it's not from a DNS perspective and to notify them of such.

Another option would be to delay the showing of any packets until DNS returns, but to show the original ICMP latency. That would give the feeling that things didn't work, but then a lot of icmp packets came back with low latency, and I feel like that would still cause the user to doubt the validity of the results, I know I'd be immediately skeptical.


Also available in: Atom PDF