Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Story of the PING Program (1997)

ftp.arl.mil

Post reply on HN
Print view View original

11–20 of 30 posts

Re: The Story of the PING Program (1997)

#11

Post by oftenwrong »

PeterWhittaker wrote: post #9

I 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.

Some versions of ping have -a ("audible") option to ring the terminal bell on each response.

Re: The Story of the PING Program (1997)

#14

Post by B-Con »

lbenes wrote: post #3

Am 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…

> Am I the only one that finds the MS Windows ping more useful for quick troubleshooting that the Linux/Unix variants?

If you can read the output, or just recognize the difference between successful and unsuccessful lines, it works just as well for this.

> Is this a fundamental design flaw?

It's handy UX, but not the fundamental purpose of ping.

Re: The Story of the PING Program (1997)

#15

Post by mikeash »

lbenes wrote: post #3

Am 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…

One theoretical problem with this is that it's impossible to know for sure that a packet has been lost and there's no one-size-fits-all timeout to use. On most links it doesn't matter too much, but that may be the reasoning. I've seen ping times spike in excess of two minutes on real-world internet connections (abusing 1xRTT data through a RAZR back when those were still cool) and it was... if not useful, at least interesting, to know that the data wasn't actually being dropped but was just taking a really long time.

Re: The Story of the PING Program (1997)

#16

Post by mikeash »

PeterWhittaker wrote: post #9

I 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.

My first thought is that if you had to do that these days, you'd just run a terminal app on your phone over WiFi or something of the sort. My second thought is that the vocoder solution is basically setting up a one-way human-compatible wireless network over sonar.
Post reply on HN