7

I'm pinging the same host from the same machine at the same time. And when using -f, the result is almost twice as good:

[root@localhost Desktop]# ping 196.1.6.16
PING 196.1.6.16 (196.1.6.16) 56(84) bytes of data.
64 bytes from 196.1.6.16: icmp_seq=1 ttl=62 time=0.744 ms
64 bytes from 196.1.6.16: icmp_seq=2 ttl=62 time=0.166 ms
64 bytes from 196.1.6.16: icmp_seq=3 ttl=62 time=0.164 ms
64 bytes from 196.1.6.16: icmp_seq=4 ttl=62 time=0.164 ms
64 bytes from 196.1.6.16: icmp_seq=5 ttl=62 time=0.167 ms

[root@localhost Desktop]# ping -f 196.1.6.16
PING 196.1.6.16 (196.1.6.16) 56(84) bytes of data.
.^C
--- 196.1.6.16 ping statistics ---
84226 packets transmitted, 84225 received, 0% packet loss, time 9782ms
rtt min/avg/max/mdev = 0.083/0.091/0.191/0.012 ms, ipg/ewma 0.116/0.090 ms

I just wonder why. As I understand it, it doesn't matter how frequently I send packets, time should be the same.

As I have such different results, which one of these two is "fair"?

UPDATE #1

When it's interesting by itself, another reason I'm asking this - because I want to have better latency (I perform HFT trading). So if "flood" ping somehow improves latency, then I want to know how and why. If it zeros some buffer, then I should evaluate if it makes sense to zero this buffer in a persistent manner etc.

UPDATE #2

The difference is far more when pinging 127.0.0.1

[root@localhost Desktop]# ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
....
64 bytes from 127.0.0.1: icmp_seq=17 ttl=64 time=0.067 ms
64 bytes from 127.0.0.1: icmp_seq=18 ttl=64 time=0.058 ms
64 bytes from 127.0.0.1: icmp_seq=19 ttl=64 time=0.064 ms
64 bytes from 127.0.0.1: icmp_seq=20 ttl=64 time=0.067 ms
^C
--- 127.0.0.1 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 18999ms
rtt min/avg/max/mdev = 0.058/0.065/0.069/0.006 ms


[root@localhost Desktop]# ping -f 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
^C 
--- 127.0.0.1 ping statistics ---
92267 packets transmitted, 92267 received, 0% packet loss, time 1273ms
rtt min/avg/max/mdev = 0.005/0.005/0.065/0.003 ms, ipg/ewma 0.013/0.006 ms

UPDATE #3

I tuned my system a little bit, in particular i've used tuned-adm and switched to network-latency. Now numbers are lower but I still have the same problem - when flooding ping is MUCH better, why?

[root@localhost]# ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.011 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.010 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.009 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.011 ms
64 bytes from 127.0.0.1: icmp_seq=5 ttl=64 time=0.011 ms
64 bytes from 127.0.0.1: icmp_seq=6 ttl=64 time=0.011 ms
64 bytes from 127.0.0.1: icmp_seq=7 ttl=64 time=0.011 ms
^C
--- 127.0.0.1 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 5999ms
rtt min/avg/max/mdev = 0.009/0.010/0.011/0.003 ms

[root@localhost]# ping -f 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.

^C--- 127.0.0.1 ping statistics ---
42294 packets transmitted, 42294 received, 0% packet loss, time 837ms
rtt min/avg/max/mdev = 0.003/0.003/0.025/0.002 ms, ipg/ewma 0.019/0.003 ms

I'm using RHEL 7, latest kernel, all updates.

Improve this question
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

2 Answers 2

Reset to default
2

Answering your update: I don't know anything about HFT trading, but I can practically guarantee that it doesn't take place over ICMP (the protocol used for pinging). Since ICMP messages are likely to be buffered and prioritized differently than traffic carrying your actual data (most likely using TCP or UDP), the ping results are not directly relevant to what you are trying to accomplish.

Improve this answer
1
  • i understand that. ICMP can not be used for "precise" evaluation, because it's low-priority and we should evaluate actual TCP or UDP traffic. at the same time ICMP is easiest way to have some estimate. and if you have unexpectedly slow ping, twice slower than you expect, then you want to know why. what is the reason for it to be so much slower, what if this affects TCP/UDP traffic too? Commented Oct 17, 2014 at 8:30
0

According to ping man pages, the f flag is:

  • -f: Flood ping. For every ECHO_REQUEST sent a period ''.'' is printed, while for ever ECHO_REPLY received a backspace is printed. This provides a rapid display of how many packets are being dropped. If interval is not given, it sets interval to zero and outputs packets as fast as they come back or one hundred times per second, whichever is more. Only the super-user may use this option with zero interval.

So with using the f flag, I got:

[support@cloudHA1 exporttool]$ sudo ping -f www.google.com
[sudo] password for support:
PING www.google.com (74.125.228.51) 56(84) bytes of data.
..^C
--- www.google.com ping statistics ---
12502 packets transmitted, 12500 received, 0% packet loss, time 29394ms
rtt min/avg/max/mdev = 1.335/2.194/191.342/6.182 ms, pipe 2, ipg/ewma 2.351/1.524 ms
[support@cloudHA1 exporttool]$

Without the flag, I got:

[support@cloudHA1 ~]$ ping www.google.com
PING www.google.com (74.125.228.50) 56(84) bytes of data.
64 bytes from iad23s06-in-f18.1e100.net (74.125.228.50): icmp_seq=1 ttl=49 time=1.53 ms
64 bytes from iad23s06-in-f18.1e100.net (74.125.228.50): icmp_seq=2 ttl=49 time=1.51 ms
64 bytes from iad23s06-in-f18.1e100.net (74.125.228.50): icmp_seq=3 ttl=49 time=1.72 ms
64 bytes from iad23s06-in-f18.1e100.net (74.125.228.50): icmp_seq=4 ttl=49 time=1.62 ms
64 bytes from iad23s06-in-f18.1e100.net (74.125.228.50): icmp_seq=5 ttl=49 time=1.78 ms
64 bytes from iad23s06-in-f18.1e100.net (74.125.228.50): icmp_seq=6 ttl=49 time=1.66 ms
64 bytes from iad23s06-in-f18.1e100.net (74.125.228.50): icmp_seq=7 ttl=49 time=1.59 ms
64 bytes from iad23s06-in-f18.1e100.net (74.125.228.50): icmp_seq=8 ttl=49 time=1.66 ms
64 bytes from iad23s06-in-f18.1e100.net (74.125.228.50): icmp_seq=9 ttl=49 time=1.43 ms
64 bytes from iad23s06-in-f18.1e100.net (74.125.228.50): icmp_seq=10 ttl=49 time=1.72 ms
64 bytes from iad23s06-in-f18.1e100.net (74.125.228.50): icmp_seq=11 ttl=49 time=1.84 ms
64 bytes from iad23s06-in-f18.1e100.net (74.125.228.50): icmp_seq=12 ttl=49 time=1.80 ms
64 bytes from iad23s06-in-f18.1e100.net (74.125.228.50): icmp_seq=13 ttl=49 time=1.69 ms
64 bytes from iad23s06-in-f18.1e100.net (74.125.228.50): icmp_seq=14 ttl=49 time=1.87 ms
64 bytes from iad23s06-in-f18.1e100.net (74.125.228.50): icmp_seq=15 ttl=49 time=1.84 ms

^C
--- www.google.com ping statistics ---
61 packets transmitted, 61 received, 0% packet loss, time 60530ms
rtt min/avg/max/mdev = 1.438/2.026/12.749/1.548 ms

I will add the i flag as well in this next example, which according to the ping man page does this:

  • -i interval Wait interval seconds between sending each packet. The default is to wait for one second between each packet normally, or not to wait in flood mode. Only super-user may set interval to values less 0.2 seconds.

    [support@cloudHA1 ~]$ ping -fi 4 www.google.com PING www.google.com (74.125.29.106) 56(84) bytes of data. ^C --- www.google.com ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 13875ms rtt min/avg/max/mdev = 9.381/9.531/9.749/0.153 ms, ipg/ewma 4625.308/9.495 ms [support@cloudHA1 ~]$

Improve this answer
9
  • 3
    This answer does not explain why round-trip time is decreased when packets are sent more frequently. Commented Oct 15, 2014 at 21:05
  • 1
    But you didn't answer the OP. Where does it say, "reply packets will be received sooner if you send more of them"? Commented Oct 15, 2014 at 21:12
  • 1
    @ryekayo Add the -i interval portion from man ping and it should complete the answer. Commented Oct 15, 2014 at 21:42
  • 5
    I don't understand this answer. ryekayo's average rtt is higher when using the -f option. So 1. the OP's claim can't be reproduced, 2. the excerpts from the man page don't give the slightest hint at which measurement is more accurate and 3. what's a "fair" result anyways? Commented Oct 15, 2014 at 22:17
  • 1
    You appear to have misunderstood the OP. They were asking why the response time is quicker, not why the frequency at which the requests were sent is higher. Commented Sep 17, 2015 at 17:51

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.