Skip to main content
Unix & Linux

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

Required fields*

7
  • 1
    It would be interesting to run these 2 ping invocations in parallel and see the results then. Also, it would be good to show the statistics footer on the first ping as well. Commented Oct 15, 2014 at 20:12
  • Very interesting observation. I can confirm the same phenomena on my system. Running the pings in both serial and parallel shows that the non-flood pings are faster when simultaneous with the floor then when run alone. I'm guessing some sort of adaptive packet prioritization is occurring, but I don't really know. Commented Oct 15, 2014 at 21:03
  • My first guess is buffering. Something along the path is buffering the ICMP packets and sending them grouped together. This might result in the first packet in the buffer being slightly delayed, but the net result is lower since there's less frames being sent across the network (less resource contention). Commented Oct 16, 2014 at 1:27
  • i'm sorry i didn't included statistics footer for the first ping - just believe me average was 165+-5 microseconds. this is local network so pings are very "stable" (i.e. produce same value). I will try to run parallel normal ping and "average" ping. Commented Oct 16, 2014 at 8:51
  • my another quess - can it be because of ARP lookup? how much ARP table lives? what if normal ping do fresh ARP lookup every second, and so every time? but flood ping do ARP lookup every second, so only once per 10000 times? if this is the reason, then i can use static ARP table and so significantly decrease latency. Commented Oct 16, 2014 at 9:04