これを見たのはこれが初めてで、それが何を意味するのかわかりません。
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時間を目にしたことがありますか?私の友人は、ワイヤレスリンクで一度見たと言っていました。これはワイヤレス接続を介したものでしたが、どうしてですか?
NTPまたはWindowsTime Serviceはping中にシステムクロックを同期しましたか?
信じがたいですが この議論 これは特定のAMDCPUの動作であることを示しているようです。
個人的には、それについて心配する必要はなく、ICMPの概念上の欠陥だと思います...おそらく、パケットが別のパスを通過したか、クロックが異なるマシン/ルーターに関係する奇妙なものです。
残念ながら、これはAMDプロセッサに限定されるものではありませんが、XPにかなりの影響を与えるようです。これまで、数年にわたって回答を検索した結果、簡単な修正方法はわかっていますが、起動後にリモートで再表示されないサーバーに対しては実行できません。
TCP/IP(およびタイミング)をリセットするには、管理CMDウィンドウを開き、次のように入力します。
ipconfig /flushdns
arp -d
gpupdate /force
netsh int ip reset null
netsh winsock reset
ここで、再起動する必要があります。ネットワークアダプタはDHCPに戻るため、リモートに注意してください。
では、ここで何が起こるのでしょうか?
何らかの理由で、TCP/IPにはタイミングの計算に使用するタイムスタンプがあり、なんらかの理由で混乱します。以前は一か所で見ていましたが、やっと止まりました。残念ながら、私が管理している倉庫では継続しています。今夜、すべてのポイントが237msでスタックしているように見えますが、2つが複数のpingでポップバックしました。
pingpath
は非常に便利なユーティリティであり、これをより頻繁に使用します。残念ながら、同じ結果が出ました...
悲しいことに、これによりゲームでのpingの誤カウントも解消されます。
注-ログファイルを表示する場合は、nullをc:\log.txt
などのファイル名に置き換えます-nullは、ファイルがないことを意味します(技術的に)
これは、ping
コマンドがパケットを計測する方法のバグであり、IntelよりもAMDプロセッサによって悪化すると思います。
Windowsで高解像度のタイミングに使用される関数は、QueryPerformanceCounter
とQueryPerformanceFrequency
です。
残念ながら、これらのプロセッサは同じ番号を返さないため、マルチコアプロセッサでは壊れています。
Pingの修正は、スレッドアフィニティをping
に設定することです。ネガティブなタイミングを説明するようなことをしているのではないかと思います。それを整理するのに役立つはずのAMDとMSからのパッチもあります。