RTSしきい値、断片化、およびその他の高度なWiFi設定
背景：私は騒々しい環境にあり、WiFiネットワークを最適化して、やや大量のユーザー（多忙な日には約50〜75人）に対してより安定した接続を確立しようとしています。 APは4つあり、チャネルと送信電力を調整済みですが、全体的にかなりまとまった範囲です。ただし、Googleにpingして建物内を歩き回り、APからAPにローミングすると、約10％のパケットドロップが発生します。
私が見たほとんどのWiFi APでは、デフォルトのRTSしきい値は2347に設定され（さまざまな場所で読んだものから、この設定は「無効」としてカウントされます）、フラグメンテーションしきい値は2346に設定されています。私の特定のブランドのルーターは2346と2346に設定されています。いくつか質問があります...
2346の値はどこから得られますか？それはやや恣意的であるように見えますが、Fragの注釈です。しきい値は、256以上で偶数である必要があることを示します。
RTSとFragはどうですか。しきい値関連？それらの値は偶然ではありません。
変更した場合、一緒に変更する必要がありますか？
手始めに、それらを下げることを試みるのに安全な値は何ですか？
私の優先事項は、必ずしも各デバイスのピーク帯域幅を取得することではありませんが、ユーザーに安定した一貫した帯域幅/接続を提供することです。
2346が最大です 802.11フレーム サイズ。 RTSと断片化のしきい値を最大に設定すると、しきい値を満たすパケットがなくなります。
断片化のしきい値により、最大フレームサイズが制限されます。これにより、フレームの送信に必要な時間が短縮されるため、フレームが破損する可能性が低くなります（データオーバーヘッドが増加します）。 RTSしきい値は、トランスミッタが RTS/CTS プロトコルを使用する必要があるフレームサイズを指定します。これは、主に 非表示ノードの問題 を解決するためのものです。これは明らかにオーバーヘッドも追加します。
必ずしもそうとは限りません-隠しノードの問題がない場合、RTSしきい値を変更してもパフォーマンスは向上しません。ただし、RTS/CTSがRTSしきい値を開始するためには、フラグメンテーションしきい値と同じかそれよりも小さい必要があります。
まず、標準のイーサネットフレームが2つの802.11フレーム（1500/2 = 750バイトのペイロード+ 34バイトのオーバーヘッド= 784バイト）にフラグメント化され、標準のイーサネットフレームの3分の1より大きいフレームはRTSを使用するように設定します（534バイト）。
私の知る限りでは、これらの設定は両方ともトランスミッタにのみ影響します。つまり、APでこれらを設定すると、APが送信に使用するだけで、クライアントは送信に使用しません。
その混合b/gシナリオは特に次善です。次のようなトピックに関するこれまでのディスカッションのいくつかを確認することをお勧めします。
最も遅いワイヤレスクライアントが他のすべての接続品質を決定しますか？
また、ポイントAはポイントBの信号を受信できるが、BはAの信号を受信できない場合にも、別のパフォーマンスキラーが発生します。 ServerFaultの他の誰かがこれを「隠れた送信機効果」と指摘しました。以下のリンクでその現象の詳細をご覧ください。彼らはそれを指摘します：
「...水平偏波が望まれますが、安価な商用水平偏波無指向性アンテナがないため、垂直偏波アンテナの使用が必要になる場合があります。優れた無指向性垂直偏波アンテナは、パラボラアンテナとほぼ同じコストです無指向性アンテナを使用すると、「隠れた送信機」の影響を最小限に抑えることができます。 "
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の衝突から回復する必要があるかはわからないため、RTS/CTSを使用してもほとんど利益がありません。多くの違い。 RTSの衝突からの回復は、RTSパケットが非常に小さいのに対し、データパケットは通常そうではないためによくなります。ただし、非常に小さなデータパケットの場合、RTS/CTSはオーバーヘッドを追加するだけで、実用的なメリットはありません。
また、断片化のしきい値によってネットワークパフォーマンスがどのように向上するかについても理解しました。一方では、送信されるパケットのサイズが制限され、前述のように、衝突のパケットが小さいほど、ネットワークはパケットからより速く回復します。一方、衝突があった場合、パケット全体ではなく、影響を受けるフラグメントのみを再送信する必要があります。ただし、送信されるすべてのフラグメントには独自のオーバーヘッドがあるため、送信されるフラグメントが増えるほど、オーバーヘッドが増加し、オーバーヘッドは基本的にはデータ伝送に使用されたはずの帯域幅を浪費します。