Administrace komentářů

Ta hodnota RTS thr (někdy se tomu taky říká RTS treshold) není nic jiného než velikost paketu, při které se zapíná kontrola RTS/CTS. Manuálová stránka neříká nic o tom, jestli jsou to bity nebo byty. Spíš bych se ale přikláněl k těm bytům. Že některé zařízení neumí nastavovat liché délky apod., to je vcelku běžná věc.

Funguje to takhle: Když je paket menší než treshold, pošle se přímo, tj. "bez dovolení". Je tam potom jisté riziko, že se dostane do konfliktu s jinými pakety a že budou pak všechny poškozené a budou se muset poslat znova. Protože je ale paket krátký, předpokládá se, že takové výpadky jsou málo pravděpodobné. (Stojí za to riskovat a ušetřit overhead.)

U dlouhého paketu už takový přístup volit nelze. Proto jsou pakety větší než treshold přenášené "s dovolením", tj. napřed se pošle výzva a pak teprve (po obdržení odpovědi) samotný paket. Při tomto způsobu je zajištěno, že bude v té době kanál volný. Čím nižší je RTS treshold, tím častěji se používá RTS/CTS, tj. komunikace je lépe řízená, ale má mnohem větší overhead. Treshold lze nastavit i na nulu, což je ovšem dvojsečná zbraň, jako ostatně všechny extrémní hodnoty.

Z předchozího plyne: Není potřeba mít na klientech a na AP nastavené stejné hodnoty RTS treshold.

Připadá mi, jako by se buď u mastera nebo u některého z klientů nenastavovala automaticky rychlost. Všechny musí mít nastavené iwconfig ethX rate auto. Těch 80-90 kBps mi nápadně připomíná hodnotu 1 Mbps + overhead. Možná některý z klientů při nějakém chvilkovém šumu (zapnutí mikrovlnky, broušení, svařování atd...) snížil rychlost na 1 Mbps a pak už ji nezvýšil, když bylo potřeba. Je rychlost zhoršená mezi každými dvěma klienty?