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ů.

Protože AP Vlára jede na OS Mikrotik, který do verze 3.x nepodporoval RTS/CTS, spočívá jediná cesta, jak tento problém řešit, v nastavení QoSu pro Upload tak, aby se na APčku dostali občas k "lizu" i ti nejpostiženější (nejskrytější) uživatelé.

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ů. Pro to si napíšeme tento skript:

 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ů!