web-dev-qa-db-ja.com

pingのこの変動の原因は何ですか?

インターネット接続に問題があり、原因がわかりません。

私のルーターはLinksys E32で、私のコンピューターにはWindows 8とWIFIアダプターが装備されていますTP-Link WDN3200(Ralink 5572)最新のものですRalinkのドライバー。

inSSIDer3を使用すると、次の統計が得られます。

ChannelsDetails

私のルーターと隣人の間のギャップは十分なはずだと思います。

ルーターに対してpingテストを実行すると、次の統計が得られます。

C:\>ping 192.168.0.1 -n 1000

Pinging 192.168.0.1 with 32 bytes of data:
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1586ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1995ms TTL=64
Reply from 192.168.0.1: bytes=32 time=13ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1993ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2000ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=4ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1994ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1995ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1990ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
...

ここに表示されている2-good-1-badパターンに興味があり、これから逸脱することはめったにありません。時々私はリクエストがタイムアウトしましたを取得します。

WIFIのみ(データが無効)を使用している携帯電話(Samsung Galaxy Nexus)では、pingテスト中にルーターから継続的に良好な応答が返されます。

VPN +リモートデスクトップを仕事に使用するのは良い経験ではなく、ブラウザでWebサイトにアクセスしようとすると、ルックアップが遅くなるようです。

誰かが私に問題が何であるかを判断するように導くことができますか?


更新:

ケーブル接続されたLAN接続を使用すると、常に1ミリ秒未満のping結果が得られます。

2
Chau

可能性の高い順に、私の最善の推測:

  1. システム上で、3秒ごとにWi-Fiスキャンを実行するソフトウェアを実行しています。たぶん、inSSIDer、または他の「ネットワークスキャナー/スタンブラー/ウォードライビング」ツールを実行したままにしました。または、定期的なスキャンを実行するWi-Fiベースのジオロケーションを実行しようとしているシステムに何かがあるかもしれません。スキャンのもう1つの可能なソースは、ローミング先の他のネットワークを探しているときの独自のワイヤレスカードです。ただし、スクリーンショットの1つでは、RSSI(信号強度)は-60 dBmであり、これはかなり良好であるため、クライアントはおそらくローミングスキャンを実行しようとしてはなりません。したがって、スキャンをトリガーする可能性のあるものを探しに行き、テストとして今のところすべてを無効にします。

  2. クライアントは、トラフィックが少ないときに無線を一時的にスリープ状態にする、なんらかの形の802.11省電力モードを実行しています。 Windowsでは、Wi-Fi NICドライバーの高度なドライバープロパティに移動し、これがクリアされるかどうかを確認するためのテストとして省電力モードを無効にすることができます。

  3. 可能性ありだと思いますが、非常に定期的な問題(ほぼ正確に3秒ごとにほぼ正確に2秒の一時停止)が干渉によるものである可能性はほとんどありません。 「2秒オン、2秒オフ」のデューティサイクルで何かがノイズを吐き出す可能性があると思いますが、それは本当にストレッチのようです。

4
Spiff

注意すべきことの1つは、Wifiチャネルに干渉する複数の重複チャネルがあるという事実です。これにより、ネットワークトラフィックに問題が発生します。 MariusMatutiaeのアドバイスを受けて、有線で接続しているときにルーターにpingを実行しようとすると、これは問題にならないはずです。 Wifiを使用する場合は、同一チャネルと重複チャネルという2つの異なる問題を考慮する必要があります。

同一チャネル

同一チャネルは、同じチャネル上の複数のネットワークです。 Wi-Fiは本質的に半二重であるため、これにより問題が発生します。つまり、両方を同時に送信または受信することはできません。したがって、APまたはコンピュータが送信しようとすると、そのチャネルで「ジャム」信号を送信して、ブロードキャストしようとしていることを示し、そのチャネルの他のすべてのワイヤレス送信機はブロードキャストを停止します。これは、トラフィックの忠実度を確保するためです。ジャムはそれほど長くはありませんが、他の人が放送できないことを意味します。今、私が理解しているように、あなた自身だけでなく他のwifiネットワーク(ssids)があなたの信号によって妨害され、あなたは他のssidsによって妨害されます。そのため、隣人がネットワークを送信しようとするたびに、妨害も発生します。

重複するチャネル

私の意見では、重複するチャネルはさらに悪いです。この場合、あなたはあなた自身に非常に近い周波数を持っていて、それ自体があなた自身の信号との干渉を引き起こしています。したがって、ネットワークが11で、ネイバーが10の場合、信号は十分に接近しているため、干渉することになります。これにより、データが遅れたり文字化けしたりする可能性もあります。これは、送信機が想定されている信号を完全に送信しないために発生します。少しずれます。その結果、他のチャネルから(時々)データを受信し、(時々)ジャムや悪いデータを完全に引き起こします。

より良いガイドについては、こちらをご覧ください: https://serverfault.com/questions/471721/adjacent-channel-versus-co-channel-interference

その他のソース: http://www.metageek.net/support/adjacent-channel-congestion/

1
prateek61