5 ms·

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 performa

by lbenes 12y ago

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 along with the successful ones. Why is Linux ping this way? Is this a fundamental design flaw?

Adaptive 12y ago
On current iputils ping (seems to be default on most linux distros) you should be using flood ping for this: # ping -f x.x.x.x As superuser or su -c / sudo of course. You'll get a nice real time bar chart of packet loss. I use it all the time for (edit: local) network testing.
- 300bps 12y ago
  That's fine on your local network. If you're pinging a system out of your local network, what you're doing is considered by many to be a denial of service attack. http://en.wikipedia.org/wiki/Ping_flood http://en.wikipedia.org/wiki/Ping_flood It's not even close to the most effective denial of service attack, but if I were to do that from my 100 Mbps Internet line I could overwhelm many company's Internet lines with a simple ping flood.
  - Adaptive 12y ago
    Sure. I added "local" about a second after posting for this reason. However even with -f you can just specify an interval when running tests outside your lan.
kruczek 12y ago
It still writes icmp_seq, which increases by one for each subsequent packet sent - based on this you can spot any missing responses. Indeed not as visible as in Windows though.
Palomides 12y ago
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).
switch007 12y ago
'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 Also, in standard ping, you can type Ctrl+\ (sends the QUIT signal) to get an update, e.g. $ ping msn.com PING msn.com (23.101.196.141) 56(84) bytes of data. <<< Ctrl+\ >>> 7/0 packets, 100% loss
- Moru 12y ago
  ctrl+break does the same on windows ping.
aw3c2 12y ago
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.
B-Con 12y ago
> 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.
mikeash 12y ago
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.

by lbenes 12y ago

Adaptive 12y ago

On current iputils ping (seems to be default on most linux distros) you should be using flood ping for this: # ping -f x.x.x.x As superuser or su -c / sudo of course. You'll get a nice real time bar chart of packet loss. I use it all the time for (edit: local) network testing.

300bps 12y ago
That's fine on your local network. If you're pinging a system out of your local network, what you're doing is considered by many to be a denial of service attack. http://en.wikipedia.org/wiki/Ping_flood http://en.wikipedia.org/wiki/Ping_flood It's not even close to the most effective denial of service attack, but if I were to do that from my 100 Mbps Internet line I could overwhelm many company's Internet lines with a simple ping flood.
- Adaptive 12y ago
  Sure. I added "local" about a second after posting for this reason. However even with -f you can just specify an interval when running tests outside your lan.

kruczek 12y ago

It still writes icmp_seq, which increases by one for each subsequent packet sent - based on this you can spot any missing responses. Indeed not as visible as in Windows though.

Palomides 12y ago

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

switch007 12y ago

'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 Also, in standard ping, you can type Ctrl+\ (sends the QUIT signal) to get an update, e.g. $ ping msn.com PING msn.com (23.101.196.141) 56(84) bytes of data. <<< Ctrl+\ >>> 7/0 packets, 100% loss

Moru 12y ago
ctrl+break does the same on windows ping.

aw3c2 12y ago

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.

B-Con 12y ago

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

mikeash 12y ago

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.