Próg RTS, fragmentacja i inne zaawansowane ustawienia Wi-Fi

Tło: Jestem w hałaśliwym otoczeniu i próbuję zoptymalizować moją sieć Wi-Fi, aby uzyskać bardziej stabilne połączenie dla dość dużej liczby użytkowników (~ 50-75 w pracowity dzień). Są 4 AP, a ja już dostosowałem kanały i moc nadawania, i ogólnie mam dość przyzwoity zasięg. Nadal jednak dostaję około 10% upuszczenia pakietów podczas pingowania Google'a i chodzenia po budynku, wędrując od AP do AP.

W większości punktów dostępowych WiFi, które widziałem, domyślny próg RTS jest ustawiony na 2347 (z tego, co przeczytałem w różnych miejscach, ustawienie to liczy się jako „wyłączone”), a próg fragmentacji jest ustawiony na 2346. Moja szczególna marka routera jest ustawiony na 2346 i 2346. Mam kilka pytań ...

1. Skąd pochodzi wartość 2346? Wydaje się to jednak nieco arbitralne, notatki do Frag. Próg wskazuje, że musi to być ponad 256 i liczba parzysta.

2. Jak tam RTS i Frag. Związane progi? Ich wartości nie mogą być przypadkowe.

3. Jeśli zmodyfikowane, czy powinny być zmieniane razem?

4. Jaka jest bezpieczna wartość, aby spróbować je obniżyć na początek?

Moim priorytetem niekoniecznie jest uzyskanie maksymalnej przepustowości dla każdego urządzenia, ale zapewnienie użytkownikom stabilnej, spójnej przepustowości / połączenia.

1. 2346 to maksymalny rozmiar ramki 802.11 . Ustawienie progów RTS i progów fragmentacji na maksimum oznacza, że ​​żaden pakiet nie osiągnie progu.

2. Próg fragmentacji ogranicza maksymalny rozmiar ramki. Skraca to czas wymagany do przesłania ramki, a zatem zmniejsza prawdopodobieństwo jej uszkodzenia (kosztem większego obciążenia danych). Próg RTS określa rozmiar ramki, przy której nadajnik musi używać protokołu RTS / CTS , co w dużej mierze służy rozwiązaniu problemu ukrytego węzła . To oczywiście także dodaje koszty ogólne.

3. Niekoniecznie - jeśli nie masz problemu z ukrytym węzłem, zmiana progu RTS nie poprawi wydajności. Aby RTS / CTS mógł zostać uruchomiony, próg RTS musi być taki sam lub mniejszy niż próg fragmentacji.

4. Zacznę od ustawienia ich w taki sposób, aby standardowa ramka Ethernet została podzielona na dwie ramki 802.11 (1500/2 = 750 bajtów ładunku + 34 bajty narzut = 784 bajtów), a każda ramka większa niż jedna trzecia standardowej ramki Ethernet używa RTS (534 bajty).

O ile wiem, oba te ustawienia wpływają tylko na nadajnik, tzn. Skonfigurowanie ich na AP powoduje, że AP używa ich do transmisji i nie zmusza klientów do używania ich do transmisji.

Ten mieszany scenariusz b / g jest szczególnie nieoptymalny. Możesz przejrzeć niektóre wcześniejsze dyskusje na ten temat, takie jak:

Najwolniejszy klient bezprzewodowy decyduje o jakości połączenia wszystkich innych?

Ponadto inny zabójca wydajności występuje, gdy punkt A może odbierać sygnał punktu B, ale B nie może odbierać sygnału A. Ktoś inny na ServerFault zwrócił na to uwagę jako „efekt ukrytego nadajnika”. Więcej o tym zjawisku pod linkiem poniżej. Wskazują, że:

”... Gdy pożądane jest polaryzacja pozioma, brak niedrogich handlowych poziomo spolaryzowanych anten dookólne mogą wymagać stosowania pionowo spolaryzowanych anten. Dobrym omni- spolaryzowana antena kierunkowa pionowo kosztuje w przybliżeniu taka sama jak parabolicznej anteny. Stosowanie antena dookólna pomaga zminimalizować efekt „ukrytego nadajnika”. ”

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

Nie zgadzam się z tym, że „jeśli nie masz problemu z ukrytym węzłem, zmiana progu RTS nie poprawi wydajności”. Korzystanie z CTR / RTS zawsze zmniejsza ryzyko kolizji danych. Ponieważ każda kolizja danych powoduje uszkodzenie danych, a tym samym wymaga ponownego wysłania danych, mniej kolizji oznacza mniejsze ponowne wysyłanie danych, a mniej ponowne wysyłanie danych może znacznie poprawić wydajność Wi-Fi; oczywiście tylko w przypadku znacznej liczby kolizji w sieci.

Aby wyjaśnić szczegóły: Węzeł zawsze musi poczekać pewien okres czasu i wyczuć kanał dla możliwych transmisji przed podaniem własnego. Tylko jeśli nie wykryje żadnych transmisji, może rozpocząć własną. Bez RTS / CTS ta transmisja jest bezpośrednio transmisją danych. Jeśli teraz oba węzły mają ten sam pomysł i rozpoczną transmisję danych prawie w tym samym czasie, transmisje te się zderzą. Powoduje to, że żadna transmisja nie jest nigdzie, ponieważ wszystkie otrzymane dane zostaną uszkodzone dla wszystkich innych węzłów i punktu dostępowego.

Jeżeli stosuje się RTS / CTS, transmisja rozpoczyna się od wysłania pakietu RTS przez węzeł po wykryciu. Tylko jeśli odpowiedź na to żądanie RTS zostanie udzielona przez odpowiedź CTS, rozpocznie się transmisja danych. Oczywiście, jeśli dwa węzły chcą transmitować w tym samym czasie, ich żądania RTS mogą również kolidować z tym samym negatywnym skutkiem, że wcale RTS nie jest odbierany. Różnica polega na tym, że cała sieć odzyska dużo szybciej po kolizji RTS niż po kolizji danych. Tak więc kolizja RTS jest mniej szkodliwa dla wydajności całej sieci niż kolizja danych.

Minusem jest to, że sam RTS / CTS sam wymaga pewnej przepustowości sieci i wprowadza nowe czasy wykrywania, podczas których nie mogą mieć miejsca inne transmisje danych ani transmisje RTS / CTS. Co gorsza, oczywiście RTS / CTS zawsze musi być wykonywane przy użyciu najwolniejszej prędkości obsługiwanej przez sieć, ponieważ w przeciwnym razie węzły obsługujące tę prędkość nie będą tego widzieć. Zasadniczo można powiedzieć, że RTS / CTS zawsze obniża teoretyczną przepustowość całej sieci, jednak jeśli sieć cierpi z powodu wielu kolizji, albo z powodu problemu z ukrytym węzłem (który może być również spowodowany przez węzły z innych sieci korzystających z tego samego kanał jako sieć) lub ponieważ Wi-Fi jest zatłoczone (ponieważ więcej węzłów zwiększa ryzyko przypadkowych kolizji), może w rzeczywistości zwiększyć rzeczywistą przepustowość. Nie liczba ukrytych węzłów,

Przeczytałem badanie (zaktualizuję i dodam tutaj link, gdy będę mógł go ponownie znaleźć), co sugeruje, że jeśli twoja sieć nie jest naprawdę mała (mniej niż może 6 węzłów i obejmuje tylko niewielki obszar) i nie jest odizolowana od innych sieci korzystające z tego samego kanału, wykorzystujące RTS / CTS prawie zawsze mają raczej pozytywny wpływ w praktyce. Dlaczego więc wartość progowa? Jeśli wysłanie danych zajęłoby tyle czasu, ile zajęłoby uzgodnienie RTS / CTS, wykorzystanie RTS / CTS jest niewielkie, ponieważ to, czy sieć musi się zregenerować po bardzo małej kolizji danych, czy po kolizji RTS, nie spowoduje duża różnica. Lepsze odzyskiwanie po kolizjach RTS polega na tym, że pakiety RTS są bardzo małe, podczas gdy pakiety danych zwykle nie. Ale w przypadku bardzo małych pakietów danych RTS / CTS po prostu dodaje narzut bez praktycznego zysku.

Teraz już wiesz, jak próg fragmentacji może poprawić wydajność sieci. Z jednej strony ogranicza rozmiar wysyłanych pakietów i jak wyjaśniono powyżej, im mniejszy pakiet w kolizji, tym szybciej sieć się po nim odzyska. Z drugiej strony, jeśli doszło do kolizji, tylko fragment, którego dotyczy, musi zostać wysłany ponownie, a nie cały pakiet. Jednak każdy wysłany fragment ma swój własny narzut, więc im więcej wysłanych fragmentów, tym więcej narzutu zostanie dodany, a narzut to w zasadzie zmarnowana przepustowość, która równie dobrze mogłaby zostać wykorzystana do transmisji danych.