わずか1ホップ先にあるWi-Fiルーターへのpingの動作が不安定で、時には非常に長いことがあります。pingを実行する192.168.1.1と、400〜800ミリ秒の遅延が生じることがあります。

試すべきことがたくさんあります（ファームウェア、ルーターの配置、APチャネルなど）が、この問題をもう少し系統的に攻撃したいと思います。

• まず、ネットワークのパフォーマンスを視覚化するにはどうすればよいですか？
• 次に、調整後に信頼性の高い比較を行えるように、特定の構成のパフォーマンスをベンチマークする方法を教えてください。

このserverfault回答には、何をすべきかについての高レベルのガイダンスがあります。ただし、最後のステップは本当にすごいことです。おそらく、あなた（つまり、私）は、専用のハードウェアに投資したくないでしょう...

以下は、最初にローカルWi-Fiネットワーク内の接続状態を理解するための優れたツールで、次にインターネットエンドポイントへのツールです。

Wifiツール

NetSpot（Mac用）

ローカルWiFI APを追跡し、SNR、チャネル、信号強度などの基本データを提供します。また、強度と干渉を示す物理空間の基本的なサイト調査を行うこともできます。APディスカバリモードでは、信号強度を経時的にグラフ化することもでき、配置をテストして干渉の可能性を調整できます。

Android向けWifi速度テスト

非常に役立ちます。マシンでシンプルなpythonサーバーを実行すると、アプリはリアルタイムの速度フィードバックを提供するいくつかのシナリオをテストできます。

もう1つの優れたAndroidアプリである Wifi Analyzerには、AP wifiチャネルがアクティブになっているものについていくつかの貴重なビューがあります。多くの作業を行わずにAPチャネルを選択するための最高の無料ツールである可能性があります。

iPerf

ローカルネットワークのパフォーマンスを理解するための評価の高いツール。2つのボックスが必要です。1つはサーバー、もう1つはクライアントです。いくつかのパラメーターを設定し、テストを実行して、帯域幅とジッターの結果を確認できます。結果をグラフ化し、パラメータを調整するためにjPerf GUIで使用することを好みます。

brew install iperf
iperf -s # on server, next one on client
iperf -c 192.168.1.XXX -P 1 -i 1 -p 5001 -f m -t 60

インターネット接続の健全性

mtr（pingとtracerouteの組み合わせ）

すべてのtracerouteホップをpingします。傾向データを提供します。クレイジーすごい。

brew install mtr
mtr 8.8.4.4

speedtest-cli

一般的なookla speedtest.netのCLIバージョン。プロジェクトのメンテナーは、それが一貫していないと宣言しますが、それでも大きな違いを測定しようとするのは便利です。

wget -O speedtest-cli https://raw.github.com/sivel/speedtest-cli/master/speedtest_cli.py
chmod +x speedtest-cli
speedtest-cli --list | head # and chose a top server (sorted by distance)
speedtest-cli --server 2761 # re-use the same server

NPAD：ネットワークパスとアプリケーション診断

エンドシステムとラストマイルネットワークの問題をトラブルシューティングするための自動診断サーバー。一連のテストを実行した後、このような[結果の概要]ページが表示されます。このNPADサーバーのリダイレクトリンクを使用して、最も近いNPADサーバー（すべてが揃っている）を見つけ、そのホスト名をテストに使用することをお勧めします。

  wget http://netspeed.usc.edu:8000/diag-client.c
  cc diag-client.c -o diag-client
# ./diag-client <server_name> <port> <target_RTT> <target_data_rate_in_MB/S>
  ./diag-client ps.psc.xsede.org 8001 30 5

私の個人的な結果：

私はこれをすべて数時間費やし、さまざまなことを試して（DD-WRTからTomatoファームウェアに切り替えて）読みました。ネットワーク層ではなく、ほとんどがBluetoothによる古き良きRF干渉だったことがわかりました！ルーターから5フィート以内にコンピューター、Bluetoothマウス、キーボードがありました。（そして、古いルーターはまだ2.4Ghzで衝突します。）

このために、AndroidでWifi Speed Testを最大限に活用し、アパート内で物事を動かしながら定期的にそれを実行しました。200msごとに更新を報告するため、干渉によってパケットがドロップされたときに明確に通信しました。

MetageekのCommon Sources of Interferenceガイドを読むことをお勧めします。（InSSIDerやその他のWifi分析ツールも優れているようです。）

私が持っていなかったツールの1つは、物理スペクトル分析メーターでした。電話とラップトップはWifi APのみを検出できますが、Bluetoothまたはその他のRFベースのテクノロジーからの干渉を検出することはできません。Metageekは、このスペース（にいくつかの素晴らしい解決策を持っているのWi-スパイとinSSIDer事務所）とうまくいけば、我々はより多くのツールは次のように出てくる参照AirShark。

上記の私のコメントで述べたように、Wi-Fiの問題の診断に一般的に使用されるツールは、実際にこの問題を引き起こす可能性があります。Wi-Fiネットワークをスキャンする場合、無線はチャネルをオフにする必要があります。通常は、APにフレームをバッファリングして「スリープ」させ、スキャンするチャネルを切り替えます。

さらに、AirDropが導入されてからのiOSおよびOS Xは、Wi-Fiラジオをオフチャネルにして他のAirDropサービスを探し、Yosemiteは定期的にチャネルをオフにしてハンドオフをサポートします。

そのため、ルーターに対するこれらのWi-Fi pingの変動もありました。

PING 192.168.0.1 (192.168.0.1): 56 data bytes
64 bytes from 192.168.0.1: icmp_seq=0 ttl=63 time=2.334 ms
64 bytes from 192.168.0.1: icmp_seq=1 ttl=63 time=1.813 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=63 time=2749.664 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=63 time=1748.912 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=63 time=748.162 ms
64 bytes from 192.168.0.1: icmp_seq=5 ttl=63 time=1.796 ms
64 bytes from 192.168.0.1: icmp_seq=6 ttl=63 time=1.806 ms
64 bytes from 192.168.0.1: icmp_seq=7 ttl=63 time=1.991 ms
64 bytes from 192.168.0.1: icmp_seq=8 ttl=63 time=1.797 ms
64 bytes from 192.168.0.1: icmp_seq=9 ttl=63 time=1.832 ms
64 bytes from 192.168.0.1: icmp_seq=10 ttl=63 time=1.713 ms
64 bytes from 192.168.0.1: icmp_seq=11 ttl=63 time=1.819 ms
64 bytes from 192.168.0.1: icmp_seq=12 ttl=63 time=1.616 ms
64 bytes from 192.168.0.1: icmp_seq=13 ttl=63 time=1.748 ms
64 bytes from 192.168.0.1: icmp_seq=14 ttl=63 time=1.677 ms
64 bytes from 192.168.0.1: icmp_seq=15 ttl=63 time=3427.213 ms
64 bytes from 192.168.0.1: icmp_seq=16 ttl=63 time=2426.371 ms
64 bytes from 192.168.0.1: icmp_seq=17 ttl=63 time=1425.634 ms
64 bytes from 192.168.0.1: icmp_seq=18 ttl=63 time=424.834 ms
64 bytes from 192.168.0.1: icmp_seq=19 ttl=63 time=1.829 ms
64 bytes from 192.168.0.1: icmp_seq=20 ttl=63 time=1.691 ms
64 bytes from 192.168.0.1: icmp_seq=21 ttl=63 time=2.038 ms
64 bytes from 192.168.0.1: icmp_seq=22 ttl=63 time=1.679 ms
^C--- 192.168.0.1 ping statistics ---
23 packets transmitted, 23 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.616/564.346/3427.213/1015.102 ms

ルーターを（TL-WR743NDからDIR-815に）切り替え、いくつかのWi-Fi USBアダプター（主にTP-LINK、私はD-Link DWA-160にも問題があると思います）を試し、2.5 GHzから5GHzとチャネルを磨きました。運が悪い、問題は持続した。

ネットワーク速度のテストを行うとき、またはビットトレントクライアントを実行するとき、pingで問題ないことに気付きました。ネットワークがアイドル状態のときにのみ変動します。

Windows 7の問題か、TP-LINKアダプターの問題かもしれませんが、Wi-Fiに少し負荷をかけると、変動がなくなり、ネットワークは正常に機能します。

これまで、Wi-Fiネットワークを維持するための小さなRustプログラムを作成しました。

// Need a constant wifi load in order not to have the ping drops.
fn wifi_load() {
  // This *might* be useful if the router suddenly supports Keep-Alive.
  // Not the case with DIR-815 though, we'll keep making new connections to it.
  let config = hyper::client::pool::Config {max_idle: 1};

  let client = hyper::client::Client::with_pool_config (config);
  loop {
    let url = "http://192.168.0.1/css/init.css";
    if let Err (err) = client.get (url) .send() {
      log! ("wifi_load] Error fetching {}: {}", url, err);
      sleep (Duration::from_secs (9));}
    sleep (Duration::from_millis (100));}}