Problém s velkým pingem
Na několika AP (naposledy na Vláře) jsme řešili problém s nefunkčním uploadem u jednoho člena, popř. dlouhým pingem při jakémkoli uploadu u jiných členů. Tj. symptomy typické pro Problém skrytých uzlů.
Jediná cesta, jak tento problém řešit, spočívá v nastavení hodnoty "RTS Threshold" na krabičkách všech členů na hodnotu 200 a především v nastavení QoSů pro Upload tak, aby se na APčku dostali občas k "lizu" i ti nejpostiženější (nejskrytější) uživatelé.
!!! Pozor - i když všichni uživatelé na APčku budou mít na krabičkách správně nastaven RTS Threshold, je potřeba QoSy správně nastavit! RTS Threshold není žádné zázračné řešení kolizí, pokud síť zatížíme upload-em, pak kolize vznikají i při posílání packetů RTS !!!!
Spolehlivé vyvolání problému
Pokud si chceme s tímto problémem vyhrát, nemůžeme čekat, až nám všichni uživatelé začnou vyrábět nějaký upload. Musíme si upload od klientů umět vyvolat sami. K tomu potřebujeme nějaký Linuxový stroj, připojený k páteři síti. Na Linuxu si nejdříve najdeme všechny krabičky připojené k danému APčku:
nmap -np80 10.143.x.2-254
Tento příkaz vám vypíše IP adresy všech WiFi krabiček ze zadaného rozsahu.
Nyní se budeme snažit ze všech krabiček stáhnout co nejvíce dat, tj. vygenerovat upload od všech připojených klientů. Ke masivnímu stahování dat z krabiček můžeme použít jeden ze standardních Debian nástrojů:
- ab (apache benchmark)
- httperf
Použití httperf
Příklad:
httperf --hog --server 10.143.x.x --uri home.asp --wsess=5,50,0 --burst-len 50 & httperf --hog --server 10.143.x.y --wsess=5,50,0 --burst-len 50 & httperf --hog --server 10.143.x.z --wsess=5,50,0 --burst-len 50 & ...
Vysvětlení parametrů:
- --hog - použití většího rozsahu zdrojových portů, než jen standardní rozsah 1024-5000, který pro větší počet paralelních spojení nemusí stačit
- --server 10.143.x.x - IP adresa krabičky
- --uri home.asp - úvodní HTML stránka u WA2204. Pokud tento celý parametr vypustíme, pak httperf bude načítat root dokument krabičky, který v případě WA2204 obsahuje pouze HTTP redirect o velikosti 384 bajtů. Větší provoz nám proto vygeneruje přístup na úvodní stránku home.asp, která má velikost cca 1000 bajtů. Konkrétně u WA2204 bez tohoto parametru dosáhneme provoz cca 200kB/s, s tímto parametrem i 350 kB/s.
- --wsess=5,50,0 --burst-len 50 - vygeneruje 5 sezení (web session) za sebou, v rámci každé session pak 50 paralelních spojení,mezi nimiž bude mezera 0 sekund.
- & - spoustí příkaz na pozadí, tj. nečeká na jeho dokončení
Použití Apache benchmark
!!!Pozor!!!! Ve verzi ab 2.0.40-dev, která je v Debian etch, je nějaký bug, takže pro větší počet paralelních spojení (např. -c 10) vůbec nefunguje - hlásí tuto chybu:
apr_poll: The timeout specified has expired (70007)
Pokud máte novější verzi, můžete to zkusit:
ab -kc 10 -t 30 http://10.143.x.a/ & ab -kc 10 -t 30 http://10.143.x.b/ & ab -kc 10 -t 30 http://10.143.x.c/ & ab -kc 10 -t 30 http://10.143.x.d/ & ...
kde 10.143.x.a, .b, .c, .d jsou IP adresy jednotlivých krabiček, které jsme zjistili příkazem nmap.
Pozn: Pokud příkaz ab váš Debian Linux nezná, udělejte:
apt-get install apache2-utils
Co to vlastně děláme?
Příkaz "ab" je zkratkou "Apache Benchmark" a provádí zátěžové testování web serveru. Web serverem je v našem případě wifi krabička, resp. její web rozhraní. Parametry "-kc 10 -t 30" znamenají "otevři 10 spojení, po dobu 30 sekund". Ampersand ("&") na konci řádky znamená "spusť příkaz na pozadí, nečekej až skončí".
Pokud celý tento skript spustíte, začne ze všech krabiček stahovat maximální rychlostí data - HTML stránky z jejich web rozhraní.
Řešení problému
Postupem uvedeným výše se na 30 sekund maximální měrou zatíží upload APčka, a vy díky tomu můžete snadno změřit, jaká je maximální propustnost jeho uploadu.
Měření musíte provést přímo na APčku, které testujete, aby zahrnovalo i případné jiné právě probíhající uploady uživatelů. Jednou z možností je podívat se do okýnka "interfaces" v Mikrotiku, které ukazuje aktuální hodnoty provozu TX/RX u jednotlivých rozhraní. Vás bude zajímat hodnota RX (příjem) u karty, která realizuje vaše AP.
Jaké hodnoty máte očekávat?
To je velmi závislé na počtu připojených uživatelů a na tom, kolik z nich je skryto před ostatními uživateli. U AP Vlára, které bylo navíc nastaveno do modu "B only", to bylo pouze 500kbit/s.
Na tuto naměřenou hodnotu pak nastavte Max-upload třídy, která ve vašem QoSu je rodičem všech uživatelů na toto AP připojených. Že je 500kbit/s málo? Bohužel, nedá se nic dělat. Pokud nastavíte do QoSu víc, nebude vám QoSit vůbec, a některým uživatelům pak síť pojede velmi špatně.
Následně spusťte skript Fair Bandwidth Sharing for simple queues, s tím, že musíte samozřejmě upravit hodnoty pro burst uploadu na vámi naměřenou hodnotu.
Pokud vám QoS pracuje správně, poznáte to okamžitě - pingy na uživatele začnou chodit s normálními hodnotami.
- !!!Pozor!!! nezatěžujte příkazem "ab" krabičku, na kterou pingáte - krabičky mají tak slabý procesor, že stahování HTML stránek z nich způsobuje velké výpadky pingu!!!
- !!!Pozor!!! pokud toto ladíte z jiného APčka pingáním od sebe na krabičku, nezapomeňte IP adresu krabičky přidat do QoS fronty jejího majitele, jinak si budete (jako já) trhat vlasy a nechápat, proč jsou ty pingy na krabičku pořád tak špatné!
Další náměty na pokusy
Pokud mají všichni uživatelé dobrý signál a jejich krabičky zvládají B+G, rozhodně nastavte AP do modu B+G - zvýší se tím celková propustnost APčka a tím i propustnost skrytých uzlů!
