これを見たのは初めてで、何を意味するのかよく分かりません。
64 bytes from 74.125.93.99: icmp_seq=6233 ttl=53 time=545.493 ms
64 bytes from 74.125.93.99: icmp_seq=6234 ttl=53 time=776.093 ms
64 bytes from 74.125.93.99: icmp_seq=6235 ttl=53 time=-705.731 ms
64 bytes from 74.125.93.99: icmp_seq=6236 ttl=53 time=52.549 ms
64 bytes from 74.125.93.99: icmp_seq=6237 ttl=53 time=44.470 ms
これまでに、負の ping 時間を見たことがある人はいますか? 友人が、ワイヤレス リンクで一度それを見たと言っていました。これはワイヤレス接続経由でしたが、どうしてそうなるのでしょうか?
答え1
NTP または Windows タイム サービスは ping 中にシステム クロックを同期しましたか?
答え2
信じ難いことですがこの議論これは特定の AMD CPU の動作であると思われます。
個人的には、心配せず、ICMP の概念的な欠陥だと考えています... おそらく、パケットが異なるパスを通過したか、クロックが異なって設定されたマシン/ルーターに関連する奇妙なことが原因です。
答え3
残念ながら、これは AMD プロセッサに限定されませんが、XP にかなり影響するようです。現在までに、そして数年にわたって答えを探し回った結果、簡単な修正方法はわかっていますが、起動後にリモートで再表示されないサーバーにはそれを実行できません。
TCP/IP (およびタイミング) をリセットするには、管理者の CMD ウィンドウを開き、次のように入力します。
ipconfig /flushdns
arp -d
gpupdate /force
netsh int ip reset null
netsh winsock reset
ここで、再起動する必要があります。ネットワーク アダプターは DHCP に戻るので、リモート操作には注意してください。
それで、ここで何が起こるのでしょうか?
何らかの理由で、TCP/IP にはタイミングを計算するために使用するタイムスタンプがあり、それが何らかの理由でごまかされます。以前は 1 つの場所で頻繁に発生していましたが、ついに停止しました。残念ながら、私が管理している倉庫では発生し続けています。今夜は、すべてのポイントが 237 ミリ秒で停止しているようですが、2 つのポイントは複数の ping で復帰しました。
pingpath非常に便利なユーティリティなので、今後はもっと頻繁に使用するつもりです。残念ながら、結果は同じでした...
悲しいことに、これによりゲーム内の ping の誤カウントも解消されます。
注: ログ ファイルを表示する場合は、null をファイル名に置き換えます (例: c:\log.txt
Null は、技術的にはファイルがないことを意味します)。
答え4
pingこれはコマンドがパケットの時間を測定する方法のバグであり、Intel よりも AMD プロセッサによって悪化すると思われます。
ウィンドウで高解像度のタイミングに使用される関数は、QueryPerformanceCounterおよびですQueryPerformanceFrequency。
残念ながら、マルチコア プロセッサは同じ数値を返さないため、マルチコア プロセッサでは機能しません。
ping を修正するには、 でスレッド アフィニティを設定しますping。これが実行されているとは思えませんが、これが負のタイミングの原因となります。AMD と MS からのパッチもあり、これがこの問題を解決するのに役立つはずです。