負のping時間？

15

これは私がこれを見たのは初めてで、それが何を意味するのか分かりません。

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時間を以前に見たことがありますか？私の友人は、無線リンクでそれを見たことがあり、これは無線接続であったと言ったが、どうしてそれが起こるのか？

— ジェフ・ウェリング
ソース

4

AMDプロセッサをお持ちですか？

— MaQleod

9

時空連続体の一時的な裂け目です。心配する必要はありません。デロリアンの鍵はどこに置いたのですか？

— ジャグラー

どのマシンでテストを実行したかは特に覚えていませんが、実行できるのは3つだけです（Intelデスクトップ1台、Macbook Pro 1台、Mac Mini 1台）。

— ジェフウェリング

12

負のpingラグは、マトリックスのグリッチです。彼らが何かを変えると起こります。

— ジェームズTスネル

15

NTPまたはWindowsタイムサービスは、ping中にシステムクロックを同期しましたか？

— ヒダラル
ソース

素晴らしい質問ですね。残念ながら、pingを実行した時刻を正確に覚えていないため、ログが並んでいるNTP同期を確認できません。

— ジェフウェリング

これは奇妙なことですが、トラブルシューティングのポイントとしては+1です。

— mbb

より良い答えが提供されず、これが今まで起こった時からより妥当な解決策を思い付くことができないので、私はこの答えを受け入れています。ありがとう。

— ジェフウェリング

仮想マシンで同じ問題が発生しましたが、NTPが時間のずれを修正することが問題であることを確認できます。service ntpd stopCentOSで修正されました（ただし、明らかに他の問題が発生します）。詳細については、この非常に興味深い質問を参照してください。

— ベンジャミン

4

私は信じがたいと思うが、この議論はこれが特定のAMD CPUからの挙動であることを示しているようだ。

個人的には、私はそれについて心配せず、それがICMPの概念的な欠陥だと思います...たぶん、異なるパスを通過したパケットか、クロックが異なるように設定されたマシン/ルーターを含む奇妙な何かでしょう。

— ジェームズ・T・スネル
ソース

2

リンクされた議論から、ICMPの概念的な欠陥に傾くことはないでしょう。AMDでは、2つのコア間にクロックスキューがあり、時間の否定的な解釈が発生しているようです。

— エヴァン

@evan：しかし、0.7秒は大きな矛盾です！

— 機械式カタツムリ

2

pingから取得するレポートは、外部ルーターのクロックとは関係ありません。パケットが宛先に送信され、応答がホストに返されるまでの時間の差です。ホストによってクロックされます。

— MaQleod

@Mechanical snailあなたは正しい、それは非常に大きいが、リンクされた議論は、ゆがみが時間とともに大きくなると言う。プロセッサが長時間実行されている場合、0.7秒は不合理ではありません。プロセッサがしばらく実行された後にのみ問題が発生するかどうかを確認するのは興味深いでしょう。

— エヴァン

@Evan：0.7秒はこれよりも深刻なバグを引き起こす可能性があるので、おそらく聞いたことがあるでしょう。

— 機械式カタツムリ

1

残念ながら、これはAMDプロセッサに限定されませんが、XPにかなりの影響を与えるようです。これまで、そして数年にわたって答えを探した後、私は簡単な修正方法を知っていますが、起動後にリモートで再表示されないサーバーにはそれを行うことができません。

TCP / IP（およびタイミング）をリセットするには、管理CMDウィンドウを開き、次を入力します。

ipconfig /flushdns
arp -d
gpupdate /force
netsh int ip reset null
netsh winsock reset

ここで、再起動する必要があります。ネットワークアダプタはDHCPに戻るため、リモートを注意してください。

ここで何が起こるのでしょうか？

何らかの理由で、TCP / IPにはタイミングの計算に使用するタイムスタンプがあり、なんらかの形で混乱します。以前は常に1つの場所で表示されていましたが、ようやく停止しました。残念ながら、それは私が管理する倉庫で継続されます。今夜、すべてのポイントは237ミリ秒で止まっているように見えますが、複数のpingで2つが戻ってきました。

pingpathは非常に便利なユーティリティであり、これをより頻繁に使用します。残念ながら、同じ結果になりました...

悲しいことに、これはゲームのpingミスカウントもクリアします。

注c:\log.txt - ログファイルを表示する場合は、nullをファイル名に置き換えます。たとえば、nullはファイルがないことを意味します（技術的に）

— ジェフ・マシューズ
ソース

1

これは、pingコマンドがパケットを計測する方法のバグであり、IntelよりもAMDプロセッサによって悪化していると思います。

ウィンドウで高解像度のタイミングのために使用されている機能があるQueryPerformanceCounterとQueryPerformanceFrequency。

残念ながら、これらのプロセッサは同じ数を返さないため、マルチコアプロセッサでは壊れています。

pingの修正は、スレッドアフィニティをに設定することpingです。ネガティブなタイミングを説明することになるのではないでしょうか。AMDとMSからのパッチもあり、それらを整理するのに役立つはずです。

— マット・H
ソース