
ワイヤレス ネットワーク上の Webex セッション [4 ~ 5 ユーザー] の品質が悪いとユーザーから苦情が寄せられています。パケット損失を測定し、受信状態が悪い原因を文書化するにはどうすればよいでしょうか。よろしくお願いします。
答え1
MTR / WinMTR または同等のものを使用します。これにより、最初のホップを含む各ホップの最小、最大、平均のレイテンシとパケット損失が表示されます。
この問題は、Webex(それが何であれ)とは関係がない可能性が高い - おそらく、WIFI ネットワークのノイズが原因である
答え2
優れたレイテンシ測定ツールはDSLReportsのスピードテスト。
これはできたWi-Fiの問題である可能性の方が高いと思いますバッファブロートバッファブロートは、バッファキューが膨大になり、空にならないとしても、パケットをドロップするのは悪いことだと勘違いするルーターによって発生します。その結果、すべての処理に多くの遅延が追加され、TCP の輻輳制御アルゴリズムが機能しなくなります。
解決策は、バッファ キューが蓄積されても空にならないボックスで、fq_codel や PIE などのスマート キューイング アルゴリズムを明示的輻輳通知 (ECN) と組み合わせて使用することです。通常、これは最も遅いリンクの直前のボックスであり、通常、最も遅いリンクはブロードバンド接続です。したがって、これは通常、ブロードバンド モデムまたはインターネット ゲートウェイ ルーター、および ISP の DSLAM または CMTS に関するものです。スマート キューイングは、ECN をトリガーし、必要に応じて、待ち時間をあまり増やさずにパケットをドロップするほどスマートであるため、TCP 輻輳制御が機能します。
バッファブロートが発生しているが、キューが蓄積しているボックスにもっと良いキューイングを導入できない場合は、ブロードバンドモデムとネットワークの残りの部分の間に、キューイングの優れたルーターを設置し、その帯域幅を人為的に制限して、両方向でほんの少しボトルネックになるようにします。これにより、キューが蓄積される場所になります。だろうバッファ キューが蓄積される前に、ECN をトリガーしてパケットをドロップするほどスマートなので、ネットワーク上のどこかにバッファ キューが蓄積される前に TCP 輻輳制御が作動します。