The Story of the PING Program (1997)
ftp.arl.mil
The Story of the PING Program (1997)
1–10 of 30 posts
Re: The Story of the PING Program (1997)
#2Sadly the author of ping, Mike Muss, died in a car accident in 2000. [1]
Re: The Story of the PING Program (1997)
#3Am I the only one that finds the MS Windows ping more useful for quick troubleshooting that the Linux/Unix variants? A few weeks ago I was dealing poor performance on my cable modem. When I pinged a valid IP, I was seeing the successful packets only. It didn't show time-out packets until the summary displayed on exit. This makes it useless for quick real-time monitoring. MS ping on the other hand will show time-outs along with the successful ones.
Why is Linux ping this way? Is this a fundamental design flaw?
Re: The Story of the PING Program (1997)
#4Am I the only one that finds the MS Windows ping more useful for quick troubleshooting that the Linux/Unix variants? A few weeks ago I was dealing poor performance on my cable modem. When I pinged a valid IP, I was seeing the successful packets only. It didn't show time-out packets until the summary displayed on exit. This makes it useless for quick real-time monitoring. MS ping on the other hand will show time-outs…
based on a quick perusal of the man page, the -O option will show something like "no answer yet for icmp_seq=19" when a packet doesn't get a response in time for the next one, and at least for me the default shows the icmp_seq which increases by one for each packet sent, but is only printed on each receipt (so you can spot missing ones).
Re: The Story of the PING Program (1997)
#5Sadly the author of ping, Mike Muss, died in a car accident in 2000. [1] [1] https://en.wikipedia.org/wiki/Mike_Muuss
No PONG received, connection error. RIP.
Re: The Story of the PING Program (1997)
#6Am I the only one that finds the MS Windows ping more useful for quick troubleshooting that the Linux/Unix variants? A few weeks ago I was dealing poor performance on my cable modem. When I pinged a valid IP, I was seeing the successful packets only. It didn't show time-out packets until the summary displayed on exit. This makes it useless for quick real-time monitoring. MS ping on the other hand will show time-outs…
'oping' fixes that issue:
$ oping msn.com
PING msn.com (23.101.196.141) 56 bytes of data.
echo reply from msn.com (23.101.196.141): icmp_seq=1 timeout
echo reply from msn.com (23.101.196.141): icmp_seq=2 timeout
echo reply from msn.com (23.101.196.141): icmp_seq=3 timeout
$ ping msn.com
PING msn.com (23.101.196.141) 56(84) bytes of data.
>>
7/0 packets, 100% lossRe: The Story of the PING Program (1997)
#7I remember years ago the SunOS documentation used to have a ping joke: http://docs.oracle.com/cd/E19504-01/802-5753/6i9g71m4p/index...
Re: The Story of the PING Program (1997)
#8Am I the only one that finds the MS Windows ping more useful for quick troubleshooting that the Linux/Unix variants? A few weeks ago I was dealing poor performance on my cable modem. When I pinged a valid IP, I was seeing the successful packets only. It didn't show time-out packets until the summary displayed on exit. This makes it useless for quick real-time monitoring. MS ping on the other hand will show time-outs…
I use mtr nowadays. It's not ping but a traceroute that updates as it goes. I find it much more useful than a plain ping in most cases.
Re: The Story of the PING Program (1997)
#9I loved the bit about piping ping through sed through vocoder, playing it on the stereo at 11, and finding the network fault by seeing which wiggled connector caused silence.
Re: The Story of the PING Program (1997)
#10The Amazon review by "A reader from Upper Volta, Uzbekistan" is priceless.