ホームネットワークでの散発的な高遅延
tl; dr私のホームネットワークは最近、27msの遅延から600msへのジャンプを経験しています。それは常に起こるわけではなく、夜に頻繁に起こるようです。原因を推測するために、どの機器を購入し、テストを実行する必要がありますか？
セットアップ
私の家には12Mb/800kbDSLがあります。私は他のWi-Fiソースから遠く離れた山に住んでいます。歴史的に（何年もの間）私はgoogle.comにpingを実行し、最大27ミリ秒の時間を取得できました。何かがネットワークまたは接続（すべての写真をiCloudと同期するiPhone）にあふれている場合、pingは2000〜6000ミリ秒の範囲にジャンプします。しかし、通常はすべてが良かった。
ただし、最近では、ネットワークは一度に数十分の間、約600ミリ秒で固定されたままになります。ネットワークにフラッディングしているデバイスが見つかりません。 （存在するかもしれませんが、私はそれを見つけていません。）接続は通常、朝は完全に正常で、夜は一般的に持続的に悪いです（ベッドで番組をストリーミングしたいときだけです！）
待ち時間が長い間、ネットワーク上の他のデバイス（私が試したものもあります）へのpingは変更されません（常に<2ms）。
失敗して混乱するトラブルシューティング
それを除外するために、すべての新しいハードウェア（DSLモデム、Wi-Fiルーター、ネットワークスイッチ）を購入しました。問題は解決しません。設定は次のとおりです。
Wi-Fi基地局をブリッジモードにして、DSLモデムをルーター（PPPoE + DHCP + NAT）として使用してみました。 DSLモデムを透過的なブリッジモードにして、最初のAirMac ExtremeでPPPoE、DHCP、およびNATを処理してみました。問題は解決しません。
すべての有線接続を切断しました（DSLモデムとWi-Fiベースステーションのみを残しました）。問題は解決しません。
私はDSLモデム（PPPoE付き）のみを使用し、独自のWi-Fiを使用しました。問題は解決しません。私はWi-Fi上のすべての古いタブレット、電話、ラップトップを探し出し、それらをオフにしようとしました。問題は解決しません。 Wi-Fi SSIDの名前を変更し、パスワードを設定して、1台のMacBookProラップトップをWi-Fi経由で接続しました。問題は解決しません。 Wi-Fi経由で別のラップトップを使用しました。問題は解決しません。
ラップトップをイーサネット経由でモデムに直接接続しました。モデムでWi-Fiを無効にし、他に何も接続していません。問題はなくなります！（私がこれをテストした3回、問題が発生しなかった可能性があります。）
ある時点で、イーサネット経由で接続されたラップトップだけで、モデムのWi-Fiをオンにし、問題が発生しました。 Wi-Fiをオンにするとすぐに、pingの待ち時間が急増しましたが、デバイスがWi-Fi経由で接続されていることはbelieveではありません。
iStumbler を使用しましたが、遅延の悪さとノイズの増加の間に相関関係はないようです。実際、SNRはWi-Fi経由で一貫して良好に見えます。
物事が悪いとき、それらは常に悪いわけではないことを忘れないでください。家の中のすべてのデバイスの電源を入れて接続しても、待ち時間が数秒（または数分、または数時間）30ms程度に低下してから、再び悪化する場合があります。
次のステップ？
私thinkiStumblerは、問題がRF問題とは関係がないことを私に示しました。（多分私は間違っていますか？）だから私はネットワーク上の実際のトラフィックである必要があると考えています。
Airport Extremeベースステーションは、いかなる種類のSNMPロギングもサポートしていません。 ActiontecC1000Aも同様です。モニターポート付きのスイッチやハブがありません。私はこれまでWiresharkを使用したことがありません。
しかし、私はお金と時間を投げるつもりですATそれを解決するためのこの問題
何を買えばいいですか？ネットワークのどこに注入すればよいですか？何を探すべきですか？ネットワーク上のすべてのパケットを監視し、ヒストグラムとグラフを作成して、1つの不良デバイスがすべての人の状況を台無しにしているかどうかを判断するにはどうすればよいですか？
編集1：すべてが正常な場合のDSL統計
+-----------------+-------------+
| Connection | Status |
+-----------------+-------------+
| DSL Downstream: | 15.869 Mbps |
| DSL Upstream: | 0.896 Mbps |
+-----------------+-------------+
DSLリンク統計
+------------------------------+---------------------+
| Link Statistic | Status |
+------------------------------+---------------------+
| Broadband Mode Setting: | Auto Select |
| Broadband Mode Detected: | VDSL2 - 8A |
| DSL Link Uptime: | 0 Days, 10H:39M:57S |
| Retrains: | 1 |
| Retrains in Last 24 Hours: | 1 |
| Loss of Power Link Failures: | 0 |
| Loss of Signal Link Failure: | 0 |
| Loss of Margin Link Failure: | 0 |
| Link Train Errors: | 0 |
| Unavailable Seconds: | 23 |
| Estimated Loop Length: | 2250 |
| Uncanceled Echo: | N/A |
| Transport Mode: | PTM |
| Path Parameter: | 201 |
| Priority: | 0 |
| Service Type: | PTM-Tagged |
+------------------------------+---------------------+
DSLパワー
+--------------+-------------------------+------------------------+
| Levels | Downstream | Upstream |
+--------------+-------------------------+------------------------+
| SNR: | 16 dB | 10 dB |
| Attenuation: | (DS1)21.7, (DS2)58.8 dB | (US1)4.3, (US2)47.8 dB |
| Power: | 16.4 dBm | 7.8 dBm |
+--------------+-------------------------+------------------------+
DSLトランスポート
+----------------------+------------------+---------------+
| Transport | Downstream | Upstream |
+----------------------+------------------+---------------+
| Packets: | 1482864 | 1088249 |
| Error Packets: | 0 | 0 |
| 24 Hour Usage: | 1225940.68 Mbits | 2420.93 Mbits |
| Total Usage: | 1225940.68 Mbits | 2420.93 Mbits |
| 30 Minute Discarded: | 0 | 3930 |
+----------------------+------------------+---------------+
DSLチャネル
+----------------+-------------+-------------+
| Channel | Near End | Far End |
+----------------+-------------+-------------+
| Channel Type: | Interleaved | Interleaved |
| CRC Errors: | 0 | 0 |
| 30 Minute CRC: | 0 | 0 |
| RS FEC: | 5873 | 29 |
| 30 Minute FEC: | 372 | 0 |
+----------------+-------------+-------------+
編集2：DSLReportsBufferbloatレポート
それ以外の場合は通常の遅延中にスピードテストを実行すると、アップロード中に問題が発生したことを示します
夜間および夜間のping時間
午後10時35分頃の急上昇は、1台のコンピューターがDropboxへのアップロードを開始したことでした。
編集3：ISPテクニカルサポートによると：
モデムは、想定されているより多くの信号を取得しています。ケーブルが送信する負荷を運ぶのに十分でない場合は、100％まで下げることができます。これをテストするには、信号を7日間下げて、ブラウジング\インターネットの方が優れているかどうかを確認します。 7日後、サーバーはテストを実行し、信号を再びブーストします。そしてその時までに、私たちは次に何をすべきかについて十分な数字を持っているでしょう。
私たちのサーバーはあなたの購入以上のものをプロビジョニングしています。技術的には、これによりインターネットが高速化されるはずですが、トラフィックによって引き起こされるpingや遅延が顧客によって観察された場合。購入した速度\信号にそれを持ってきて、顧客の構内のDSL回線が負荷を運ぶためのケーブルであるかどうかを観察することができます。
実際の/プロビジョニングされた/購入された速度
ダウン：15868/15872/12128Mbps
上：896/896/896kbps
報告された症状は、ルーター、DSLモデム、またはISPのDSLAMがリンクが混雑しているときにバッファリングするパケットが多すぎて、待ち時間が長くなる、bufferbloatの問題のように聞こえます。通常、TCPは、輻輳の証拠としてドロップされたフレームを探し、バックオフします。ただし、ルーター、モデム、またはDSLAMが永久にバッファリングし、フレームがドロップしない場合は、TCPが輻輳を緩和する機会を得ることなく、遅延が大幅に増加することになります。アップストリームまたはダウンストリームの帯域幅が飽和しているという理由だけで、レイテンシが大幅に増加することはありません。もしそうなら、あなたはほぼ確実にbufferbloatを持っています。
dslreports.comスピードテストツール を実行します。他の速度テストツールとは異なり、このツールはbufferbloatの問題も測定および報告します。これにより、ダウンストリームまたはアップストリームの帯域幅をすべて使用している場合（夜間にビデオをストリーミングする場合など）に高遅延が発生する可能性があります。
何かがアップロード帯域幅のすべてを使用しているときにレイテンシーがジャンプすることをすでに証明しているという事実（iCloud Photo同期の例）は、bufferbloatの問題に苦しんでいることを示す良い兆候です。
DSLモデムは、おそらくアップストリームのバッファブロート問題の原因です。 1つの解決策は、bufferbloatの問題がないことがわかっているDSLモデムを購入することです。私はこの市場を調査したことがないので、提案をすることはできません。あなたのグーグルフーはおそらく私のものと同じくらい良いです。
または、CeroWrt、OpenWrt、またはDD-WRTを実行できるホームゲートウェイの購入を検討してください。これらはすべて、CeroWrtで最初に開発/開発されたFQ_CoDelなどのバッファブロート防止テクノロジーを備えています。そのようなボックスを使用して、アップストリームとダウンストリームの帯域幅を人為的に何かに制限することによってわずかに DSLリンクが実際に可能な速度よりも遅く、そのボックスを持つことによって実際にフレームをドロップそして明示的輻輳通知の送信（ECN）その制限に達すると、永久にバッファリングする代わりに、TCPが輻輳を検出し、TCPのように元に戻すことができます。することになっています。
この* Wrtボックスをインストールするには、DSLモデムやAirMacExtremeを捨てる必要はありません。 DSLモデムと最初のAirMacExtremeの間に有線ボックスとしてインストールできます。ホームネットワークとの間のすべてのトラフィックがこのボックスを通過することを確認してください。つまり、この* Wrtボックス以外に、DSLモデムに直接接続されているデバイスがないことを確認してください。
Bufferbloatがあることがわかっている場合は、レイテンシスパイクの他の潜在的な原因を探す前に、おそらくそれを排除する必要があります。そうしないと、他のレイテンシの原因を見つける試みが妨げられます。
何かがおかしい。 24時間の統計によると：
312,600Mバイトダウン247,500Mバイトアップ
リンクレートは含まれていませんが、2KMで8Aを使用すると、おそらく15/5のリンクが得られます。 5Mb USでは、約55GB/24時間しかアップロードできませんでした。 10Mbでも250GBに達することはないので、これらの統計を信用しないでください。
それでも、これはネットワーク上のピアツーピア/同期/マルウェアが自己DOSであるように聞こえます。
更新：
接続は、古いスタイルのADSL接続（8D 0.5U、12D 0.7U、15D 1U）と、VDSL（2）（15D、3U）で通常行うことのようにバランスが取れています。これにより、自分のリンクが非常に混雑しやすい状況になります。
ネットワーク上で実行されているものはすべて、モデムが送信しようとしているが転送できるよりも速く来ている一連のフレームを保持するアップストリームキューを引き起こす可能性があります。たとえば、ラップトップからモデムまで1ミリ秒、モデムから交換まで20ミリ秒、交換からWebサイトまで5ミリ秒の代わりに、次のようになります。あなたからモデムまで1ミリ秒、フレームバッファーで100ミリ秒待機し、交換まで20ミリ秒、サイトまで5ミリ秒。送信するものが多いほど、待機時間は長くなります。
探すべきもの：ピアツーピア（ビットトレント、ゲームランチャー）同期アプリ：Windows 7/8/10 One Drive、Dropbox（esp Camera Sync）、Crashplan/BackblazeなどのiCloudオフサイトバックアップVOIP /ビデオ通話アプリ：Skype、 TS /マンブル
Webにデータを送信するもの。