Warum ist Ping bei Verwendung von -f viel schneller?

Warum ist Ping bei Verwendung von -f viel schneller?

Ich pinge denselben Host zur selben Zeit von derselben Maschine aus an. Und wenn ich verwende -f, ist das Ergebnis fast doppelt so gut:

[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

Ich frage mich nur, warum. So wie ich es verstehe, spielt es keine Rolle, wie häufig ich Pakete sende, die Zeit sollte immer gleich sein.

Da ich so unterschiedliche Ergebnisse habe, welches der beiden ist „fair“?

UPDATE #1

Wenn es an sich interessant ist, ist ein weiterer Grund, warum ich das frage: weil ich eine bessere Latenz haben möchte (ich betreibe HFT-Handel). Wenn also „Flood“-Ping die Latenz irgendwie verbessert, dann möchte ich wissen, wie und warum. Wenn es einen Puffer auf Null setzt, dann sollte ich prüfen, ob es sinnvoll ist, diesen Puffer dauerhaft auf Null zu setzen usw.

UPDATE #2

Der Unterschied ist viel größer, wenn 127.0.0.1 gepingt wird

[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

Ich habe mein System ein wenig optimiert, insbesondere habe ich verwendet tuned-admund auf umgestellt network-latency. Jetzt sind die Zahlen niedriger, aber ich habe immer noch das gleiche Problem - beim Überfluten ist der Ping VIEL besser, warum?

[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

Ich verwende RHEL 7, den neuesten Kernel und alle Updates.

Antwort1

Als Antwort auf Ihr Update: Ich weiß nichts über HFT-Handel, aber ich kann praktisch garantieren, dass er nicht stattfindet überICMP(das zum Pingen verwendete Protokoll). Da ICMP-Nachrichten wahrscheinlich anders gepuffert und priorisiert werden als der Datenverkehr, der Ihre eigentlichen Daten transportiert (höchstwahrscheinlich über TCP oder UDP), sind die Ping-Ergebnisse für das, was Sie erreichen möchten, nicht direkt relevant.

Antwort2

Laut pingManpages flautet das Flag:

  • -f: Flood-Ping. Für jede gesendete ECHO_REQUEST wird ein Punkt ''.'' gedruckt, während für jede empfangene ECHO_REPLY ein Backspace gedruckt wird. Dies bietet eine schnelle Anzeige, wie viele Pakete verloren gehen. Wenn kein Intervall angegeben ist, wird das Intervall auf Null gesetzt und Pakete werden so schnell ausgegeben, wie sie zurückkommen oder einhundert Mal pro Sekunde, je nachdem, was häufiger ist. Nur der Superuser kann diese Option mit einem Intervall von Null verwenden.

Durch die Verwendung der fFlagge habe ich also Folgendes erhalten:

[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]$

Ohne die Flagge erhielt ich:

[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

iIch werde das Flag auch im nächsten Beispiel hinzufügen , was laut der Ping-Manpage Folgendes bewirkt:

  • -i Intervall Wartezeit in Sekunden zwischen dem Senden jedes Pakets. Die Standardeinstellung ist, dass zwischen jedem Paket normalerweise eine Sekunde gewartet wird, oder im Flood-Modus nicht gewartet wird. Nur Superuser können das Intervall auf Werte kleiner als 0,2 Sekunden einstellen.

    [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 ~]$

verwandte Informationen