Nastaveni RTS/CTS

<small>Z PVwiki</small>

Zdravím po dlouhé době všechny, které zajímá problematika WiFi sítí trošku podrobněji. Nikde jsem tu nenašel důležité informace, jak by měli klienti mít správně nastavené své WiFi karty. Velice častý problém u 802.11 sítí je ten, že většina klientů má špatně nastaveno RTS/CTS.


Obsah

Proč je to tak důležité?


Protože je IEEE 802.11 vlastně standard pro vnitřní sítě, předpokládá, že naprostá většina klientů na sebe vidí. Proto se defaultně používá protokol CSMA/CA, kdy klient poslouchá svou frekvenci a vysílá, když nikdo jiný nevysílá. Jenže ve venkovním prostředí tohle neplatí, klienti na sebe nevidí téměř nikdy, takže když se používá defaultní protokol, tak klient předpokládá, že nikdo nevysílá a začne vysílat libovolněkdy. Tudíž dochází ke ztrátám paketů, nejsou výjimky ani 50% ztráty, a stačí přitom 2 klienti.

Proto je zde alternativní protokol RTS/CTS, kdy klient nejdřív požádá o vysílání, dostane od AP povolení na určitou dobu a začne vysílat, ostatní klienti po stanovenou dobu mlčí. Jenže je to velmi náročný protokol na pásmo, kdyby takto putovaly všechny pakety, sníží se propustnost sítě na cca. 25%. Protože ale u menších paketů nebývá problém ani u CSMA/CA, protože projdou tak rychle, že je riziko zarušení malé, je vhodné malé pakety nechat posílat standardním CSMA/CA. Ztráty tak budou zanedbatelné. Hodnota RTS/CTS právě udává, do jak velkého paketu v bytech se má ještě používat CSMA/CA a od jak velkého paketu používat RTS/CTS. Optimální hodnota záleží na míře ztrátovosti toho kterého bodu, většinou se nastavuje na 512, u více ztrátových na 400 i méně.

Toto nastavení se ale musí provést u VŠECH klientů!!! Nastavení na AP je k ničemu, leda byste používali na AP i u klientů Proximy, které umí tohle nastavit z AP automaticky. RTS/CTS a CSMA/CA jsou dva odlišné způsoby vysílání - bez RTS se ihned pošle paket, při RTS/CTS se nejdříve pošle RTS požadavek a čeká se na CTS reply od AP. Na wireless nemůže fungovat detekce kolizí jako na CSMA/CD, protože je to halfduplex, tj. nemůže vysílat a zároveň připoslouchat.

Ještě abych doplnil správná nastavení - hodnota by neměla být nikdy nižší než 64 bytů, jinak by neodcházely ani zprávy RTS (vesměs tam ale bývá kontrolní mechanismus), neměla by být ani vyšší než 1500 (pakety u FTP), jak jsem psal, optimum je někde okolo 500 a zapnout by to měli opravdu všichni, kdo provozují venkovní síť! A ještě jedna věc, ve které dělají lidé chybu - nastavují RTS/CTS na AP - tam to naopak nenastavujte - AP jako středobod a cíl všech paketů vidí všechny klienty, takže nemusí nikoho žádat, jestli je volno, on to ví (výjimkou jsou ony proximy, které při nastavení RTS/CTS na AP nastaví jen klienty).


Pro WiFi zařízení v síti PVfree je povinné nastavení parametru RTS / RTS Threshold na hodnotu 256.


Pokud není stanoveno jinak ponechte Fragmentation Threshold nastavený tak jak je - většinou 2432 nebo 2346. V 99% pomůže správné nastavení RTS/CTS. Při odesílání velkych paketů je vyšší pravděpodobnost, že se při přenosu vyskytne chyba a kvůli tomu se posílá celý velký paket znovu. Tim vzrůstá zatížení sítě. Pokud jeden 1500B dlouhý paket rozdělím třeba na 3x 500B paket, tak sice pošlu více hlaviček, ale při chybě při přenosu posílám znovu jen chybný blok 500B a ne celých 1500B.


Mimochodem jak máte nastavené RTS Threshold vy? Mě se osvědčila hodnota 1024. Pro větší zarušení 512.


Výrobci WiFI HW většinou napíšou jen: K dispozici jsou i parametry pro optimalizaci provozu RTS threshold (eliminuje problematiku skrytého uzlu) a Fragmentation threshold (zlepšuje prenosové parametry na zarušených trasách).


Pro WiFi zařízení v síti PVfree je povinné nastavení parametru RTS / RTS Threshold na hodnotu 256.


RTS/CTS je sice vždy přítomno, ale defaultní hodnota je tak vysoká, že se to nikdy nepoužije a je to tedy čistý CSMA (maximální velikost paketů v internetu je 1500B u FTP, plus něco na detaily v hlavičkách). Navíc když by byl paket větší než nějaká hodnota (liší se podle výrobce a nastavení, maximum bývá právě někde okolo 1500B), tak se paket rozdělí na menší (fragmentace, viz dále), takže vlastně nikdy nemůže dojít k použití RTS/CTS. Proto jsem o tom psal jako zapnout/vypnout. Pozor na to - fragmentation treshold je něco úplně jiného. WLAN standard podporuje fragmentaci paketů na menší, aby jeden paket netrval nepřiměřeně dlouho a měli šanci i ostatní. Nevím jestli je ve standardu nějaké maximum délky rámce (pravděpodobně ano), většina výrobků má ale nějakou přednastavenou hodnotu myslím okolo 1500B, potom se paket rozdělí na menší. Některé výrobky umožňují i přímo manuálně nastavit max. délku rámce, u jiných je to schované pod nějakou tajnou volbou (třeba u Proximu je zatržítko "microwave oven robustness", které právě nastavuje menší frame pro nižší rychlosti), někdy je to ovlivněno i dalším nastavením (různé max. délky rámců podle použité rychlosti a AP density). Nijak to ale nesouvisí s RTS/CTS mechanismem jen logicky když je RTS treshold vyšší než fragmentation treshold, tak se prostě RTS algoritmus nikdy neuplatní.


V každém případě když je správně nastaveno RTS/CTS, tak by měl být přínos fragmentation treshold téměř nulový - každý klient má pomocí RTS mechanismu vyhrazený prostor, do kterého mu jiný klient nevstoupí. Ovšem paket může být zarušen i z jiných důvodů než od jiného klienta, takže v hodně zarušených prostředích to také může pomoci pro kvalitu. Výhoda fragmentace je také v sítích, kde se provozují služby vyžadující lepší QoS parametry - zmenšíte-li pakety na malé hodnoty, zajistíte lepší průchodnost malým prioritizovaným paketům, tj. nebude vám nějaký dlouhý paket zabírat médium třeba půl vteřiny a nespadnou vám kvůli tomu hovory. Nevýhoda ale je ve zvýšené režii, zejména když máte klienty připojené různou rychlostí (což je btw u venkovních sítí také chyba), takže když nastavíte manuálně pevné maximum, tak 11 Mbs klient pošle stejně dlouhý paket 11× rychleji než 1Mbs klient.

Jak analyzovat ideální velikost RTS a Fragmentation threshold?


Nejlepší je, pokud jsme schopni hodnoty pro RTS a Fragmentation threshold exaktně změřit či spočítat. K tomu je určena řada specializovaného software pro analýzu paketů v bezdrátových sítích. Asi nejznámějším nástrojem je AiroPeek, AirMagnet, Linkferret a Commview for WiFI. Zajímá nás především Packet error rate - Software pro analýzu sítě by nám měl být především schopen sdělit chybovost paketů. Pokud je tato chybovost větší než 5%, je nejvyšší čas začít se zabývat optimalizací velikosti RTS threshold. Dalším důležitým údajem při ladění RTS threshold je packet size distribution. Ten nám v grafu ukáže kolik a jak velikých paketů se pohybuje v sítí (<64, 64-127, 128-255, 256-511, 512-1023, 1024-2047, 2048-2346, >=2347) Z grafu je pak vidět jak moc je zarušená síť a jak optimálně nastavit parametr RTS.

Jak nastavit RTS a Fragmentation threshold odhadem


Většině zájemců o optimalizaci WiFi sítí asi nezbude, než hodnoty nastavit odhadem a metodou pokus-omyl. Tento postup je docela jednoduchý, jen zdlouhavý a je spíše na trpělivosti administrátora, jak přesně se hodnoty podaří zoptimalizovat.

Nepříjemné je, že obě hodnoty je třeba nastavit na všech klientských adaptérech v síti, pokud na jednom z klientských zařízeních tyto hodnoty nejsou nastavené, dělá to v síti zbytečný zmatek a účinek optimalizace to snižuje. Je tedy velmi vhodné počáteční odladění provést ještě před tím, než síť spustíte do ostrého provozu, jenže to se asi nepoštěstí každému. Navíc přidání každého dalšího klienta do sítě změní podmínky v síti a je vhodné provést optimalizaci znovu.


Pro WiFi zařízení v síti PVfree je povinné nastavení parametru RTS / RTS Threshold na hodnotu 256.


Sepsal Devine.


Související odkazy

Osobní nástroje