-fを使用するとpingが速い理由

-fを使用するとpingが速い理由

同時に、同じコンピュータから同じホストにpingを送信します。以下を使用すると、-f結果がほぼ倍増します。

[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

私は理由を知りたいだけです。私が理解したところによれば、パケットをどれくらいの頻度で送信しても、時間は同じでなければなりません。

結果があまりにも違うので、どちらが「プロセス」ですか?

アップデート#1

それ自体は興味深いですが、私がこれを要求するもう一つの理由は、より良い待ち時間が欲しいからです(私は高周波取引を行います)。したがって、「フラッディング」pingが何とか待ち時間を改善する場合は、その方法と理由を知りたいです。一部のバッファをゼロに設定する場合は、継続的にバッファをゼロに設定するのが適切であるかどうかを評価する必要があります。

アップデート#2

127.0.0.1をpingすると、違いがさらに大きくなります。

[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

アップデート#3

システムを少し修正しましたが、特に使用しtuned-admて切り替えたシステムnetwork-latencyです。今数字は減少しましたが、まだ同じ問題があります。 Floodpingがはるかに良くなったのですが、なぜですか?

[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

私はすべて更新された最新のカーネルであるRHEL 7を使用しています。

ベストアンサー1

あなたのアップデートに答えるには:私は高周波取引について何も知りませんが、そのようなことが起こらないことをほとんど保証できます。ICMP(pingに使用されるプロトコル)ICMPメッセージは、実際のデータを転送するトラフィック(TCPまたはUDPを使用する可能性が高い)とは異なる方法でバッファリングされ、優先順位が付けられる可能性があるため、ping結果は実行しようとしている操作と直接関連しません。

おすすめ記事