For long latency circuits, using "ping -f -c xxxxx -l yyy -w 5" will give a receive count that is short. That is, ping will exit while packets are still in flight. The "-w deadline" option should be changed to honor "-c xxxx" packet count, and then stop transmitting pings, and wait "-w x" seconds for the stragglers to catch up.

Otherwise we cannot trust the "dropped packet count". They might not be dropped, just in transit when ping exits.

You can use -i option to control ping sending speed if you think that ping flooding might be too fast.

We use the flood option of ping to saturate a circuit. So we need the highest data rate we can generate. This is a good trick to find duplex mis-matches, faulty hardware, etc. To do this we need an accurate sent/received count.

What problem do you get? The -w ping option, waiting xx second to collect ping response, should be working.

yes, the private version of ping that I changed some years ago and that I use does that.

However, what is happening with the official version of Linux ping, and some google searches verify this, is that with the "-w deadline" option enabled, the "-c count" option is ignored, and ping continues to generate pings beyond "count" until "-w deadline" times out.

So I think the intent of "-w deadline" was to stop transmitting pings at "-c count", wait "-w deadline" seconds to allow the stragglers to catch up, and provide an accurate ping sent/receive count.

But it basically is generating the old behavior that, I think, "-w deadline" was supposed to fix.

In my ping, when "-c count" completed, I started a 2 second timer, went to sleep and continued to receive pings, and at the 2 second timer alarm went into completion and exit.

That is what we need. How do we get the code changed? I have never submitted a change request for Linux code.

The ping tool in Linux, such as Fedora 15, work fine. The -w option work like, ping does not exit after count packet are sent, it waits either for deadline expire or until count probes are answered.