RTSしきい値、フラグメンテーション、およびその他の高度なWiFi設定

背景：私は騒がしい環境にいるため、Wi-Fiネットワークを最適化して、ある程度多くのユーザー（忙しい日に50〜75）に対してより安定した接続をしようとしています。4つのAPがあり、チャネルと送信電力をすでに調整しているため、全体的にかなり適切なカバレッジがあります。ただし、Googleにpingを送信して建物内を歩き回り、APからAPにローミングすると、パケットドロップは約10％になります。

私が見たほとんどのWiFi APでは、デフォルトのRTSしきい値は2347（さまざまな場所で読んだものから、この設定は「無効」としてカウントされます）に設定され、フラグメンテーションしきい値は2346に設定されます。 2346と2346に設定されています。いくつか質問があります...

1. 2346の値はどこから得られますか？ただし、Fragのメモはややarbitrary意的です。しきい値は、256以上で偶数である必要があることを示します。

2. RTSとFragはどうですか。関連するしきい値 それらの値は偶然ではありません。

3. 変更した場合、一緒に変更する必要がありますか？

4. まず第一に、それらを下げることを試みる安全な値は何ですか？

私の優先事項は、必ずしも各デバイスのピーク帯域幅を取得することではなく、ユーザーに安定した一貫した帯域幅/接続を提供することです。

1. 2346は最大802.11フレームサイズです。RTSおよびフラグメンテーションのしきい値を最大に設定すると、しきい値を満たすパケットがなくなることになります。

2. 断片化のしきい値は、最大フレームサイズを制限します。これにより、フレームの送信に必要な時間が短縮されるため、フレームが破損する可能性が低下します（データオーバーヘッドが増加します）。RTSしきい値は、トランスミッタがRTS / CTSプロトコルを使用する必要があるフレームサイズを指定します。これは、主に隠れノードの問題を解決するためのものです。これは明らかにオーバーヘッドも追加します。

3. 必ずしもそうではありません-隠れノードの問題がない場合、RTSのしきい値を変更してもパフォーマンスは向上しません。ただし、RTS / CTSがRTSしきい値を開始するには、フラグメンテーションしきい値と同じかそれよりも小さくなければなりません。

4. 標準のイーサネットフレームが2つの802.11フレーム（1500/2 =ペイロード750バイト+オーバーヘッド34バイト= 784バイト）にフラグメント化され、標準のイーサネットフレームの3分の1より大きいフレームがRTS（534バイト）。

私が知る限り、これらの設定は両方ともトランスミッタにのみ影響します。つまり、APで設定すると、APは送信にのみ使用し、クライアントは送信に使用しません。

この混合b / gシナリオは特に最適ではありません。次のような、トピックに関する以前の議論のいくつかを確認することをお勧めします。

最も遅いワイヤレスクライアントが他のすべての接続品質を決定しますか？

また、ポイントAはポイントBの信号を受信できるが、BはAの信号を受信できない場合、別のパフォーマンスキラーが発生します。ServerFaultの他の誰かがこれを「隠された送信機効果」として指摘しました。その現象の詳細については、以下のリンクをご覧ください。彼らはそれを指摘します：

水平偏光が望まれているが、」...、安価な商業水平偏波全方向性アンテナの欠如は、垂直偏波アンテナの使用を必要とし得る。A良好な無指向性垂直偏波アンテナ、パラボラアンテナとほぼ同じ費用がかかります。の使用を無指向性アンテナは、「隠されたトランスミッタ」影響を最小限に抑えることができます。」

http://www.arrl.org/using-ieee-802-11b-operating-under-part-97-of-the-fcc-rules

「隠しノードの問題がない場合、RTSのしきい値を変更してもパフォーマンスは向上しません。」CTR / RTSを使用すると、常にデータの衝突の可能性が低くなります。データの衝突はすべてデータの破損を引き起こし、データの再送信が必要になるため、衝突が少なくなるとデータの再送信が少なくなり、データの再送信が少なくなるため、WiFiのパフォーマンスが大幅に向上します。もちろん、ネットワーク内で顕著な衝突が発生した場合のみです。

詳細を説明するには、ノードは常に一定の時間待機して、送信を開始する前に、可能な送信のチャネルを検出する必要があります。送信を感知しない場合にのみ、独自の送信を開始できます。RTS / CTSがなければ、この送信は直接データ送信です。2つのノードの両方が同じアイデアを持ち、ほぼ同時にデータ送信を開始する場合、これらの送信は衝突します。その結果、他のすべてのノードとAPのすべての受信データが破損するため、どちらの送信もどこにも送信されません。

RTS / CTSが使用される場合、送信は、センシング後にノードによって送信されるRTSパケットで開始されます。そのRTS要求がCTS応答によって応答された場合にのみ、データ送信が開始されます。もちろん、2つのノードが同時に送信したい場合、RTS要求は、RTSがまったく受信されないという同じ悪影響と衝突する可能性もあります。違いは、ネットワーク全体がRTS衝突から回復するのは、データ衝突から回復するよりもはるかに速いことです。したがって、RTSコリジョンは、データコリジョンよりもネットワーク全体のパフォーマンスに害が少ないです。

欠点は、RTS / CTS自体がある程度のネットワーク帯域幅を必要とし、他のデータ送信またはRTS / CTS送信が行われない間に新しいセンシング時間を導入することです。さらに悪いことに、当然、RTS / CTSは常に、ネットワークがサポートする最も遅い速度を使用して実行する必要があります。そうしないと、この速度のみをサポートするノードは表示されません。したがって、基本的にRTS / CTSはネットワーク全体の理論スループットを常に低下させると言えますが、隠れノードの問題（同じものを使用している他のネットワークのノードによって引き起こされる可能性があります）ネットワークとしてのチャネル）またはWiFiが混雑しているため（ノードが増えるとランダムな衝突の可能性が高くなるため）、実際のスループットが増加する可能性があります。非表示ノードの数ではなく、

私は調査を読みました（再び見つけられたらここにリンクを更新して追加します）、それはあなたのネットワークが本当に小さくなければ（おそらく6ノード未満で小さな領域のみをカバーしている）、他から隔離されていないことを示唆しています同じチャネルを使用し、RTS / CTSを使用するネットワークは、実際にはほとんど常に肯定的な効果があります。では、なぜしきい値なのでしょうか？データの送信にRTS / CTSハンドシェイクにかかる時間と同じ時間がかかる場合、RTS / CTSを使用するメリットはほとんどありません。ネットワークが非常に小さなデータの衝突またはRTSの衝突から回復する必要があるかどうかは、多くの違い。RTS衝突からのより良い回復は、RTSパケットが非常に小さいのに対し、データパケットは通常そうではないためです。しかし、非常に小さいデータパケットの場合、RTS / CTSはオーバーヘッドを追加するだけで実用的な利益はありません。

また、断片化のしきい値によってネットワークパフォーマンスがどのように改善されるかについても理解しました。一方では、送信されるパケットのサイズを制限し、上記で説明したように、衝突のパケットが小さいほど、ネットワークはより速く回復します。一方、衝突が発生した場合、パケット全体ではなく、衝突の影響を受けるフラグメントのみを再送信する必要があります。ただし、送信されるすべてのフラグメントには独自のオーバーヘッドがあるため、送信されるフラグメントが増えるほど、追加されるオーバーヘッドが増え、オーバーヘッドは基本的に無駄な帯域幅となり、代わりにデータ送信に使用できます。