Problém s velkým pingem - Historie editací

Dulik: /* Použití httperf */

2009-02-13T14:13:11Z

Použití httperf

← Starší verze		Verze z 13. 2. 2009, 14:13
Řádek 20:		Řádek 20:

	httperf --hog --server 10.143.x.x --uri home.asp --wsess=5,50,0 --burst-len 50 &		httperf --hog --server 10.143.x.x --uri home.asp --wsess=5,50,0 --burst-len 50 &
	httperf --hog --server 10.143.x.y ~~--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 ~~--uri home.asp~~ --wsess=5,50,0 --burst-len 50 &		httperf --hog --server 10.143.x.z --wsess=5,50,0 --burst-len 50 &
	...		...

Řádek 28:		Řádek 28:
	*--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		*--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		*--server 10.143.x.x - IP adresa krabičky
	*--uri home.asp - úvodní ~~strana~~ 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.		*--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.		*--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í		*& - spoustí příkaz na pozadí, tj. nečeká na jeho dokončení

Dulik v 13. 2. 2009, 14:12

2009-02-13T14:12:00Z

@@ Řádek 12: / Řádek 12: @@
 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:
+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 -kc 10 -t 30 http://10.143.x.a/ &

Dulik v 30. 11. 2008, 06:52

2008-11-30T06:52:19Z

← Starší verze		Verze z 30. 11. 2008, 06:52
Řádek 1:		Řádek 1:
	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ů („hidden nodes“) \| Problém skrytých uzlů]].		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ů („hidden nodes“) \| 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é.		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 ===		=== Spolehlivé vyvolání problému ===

195.178.89.175 v 20. 5. 2008, 08:12

2008-05-20T08:12:11Z

← Starší verze		Verze z 20. 5. 2008, 08:12
Řádek 1:		Řádek 1:
	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ů („hidden nodes“) \| Problém skrytých uzlů]].		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ů („hidden nodes“) \| Problém skrytých uzlů]].

	Protože AP Vlára jede na OS Mikrotik, který ~~nepodporuje~~ 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é.		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 ===		=== Spolehlivé vyvolání problému ===

195.178.89.175 v 28. 3. 2008, 10:16

2008-03-28T10:16:12Z

← Starší verze		Verze z 28. 3. 2008, 10:16
Řádek 1:		Řádek 1:
	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ů („hidden nodes“) \| Problém skrytých uzlů]].		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ů („hidden nodes“) \| Problém skrytých uzlů]].

	Protože AP Vlára jede na OS Mikrotik, který nepodporuje 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ší uživatelé.		Protože AP Vlára jede na OS Mikrotik, který nepodporuje 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 ===		=== Spolehlivé vyvolání problému ===

195.178.89.175 v 28. 3. 2008, 10:15

2008-03-28T10:15:42Z

← Starší verze		Verze z 28. 3. 2008, 10:15
Řádek 1:		Řádek 1:
	Na několika AP (naposledy na Vláře) jsme řešili problém s dlouhým pingem při jakémkoli uploadu. Tj. symptomy typické pro [[Problém skrytých uzlů („hidden nodes“) \| Problém skrytých uzlů]].		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ů („hidden nodes“) \| Problém skrytých uzlů]].

	Protože AP Vlára jede na OS Mikrotik, který nepodporuje 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ší uživatelé.		Protože AP Vlára jede na OS Mikrotik, který nepodporuje 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ší uživatelé.

195.113.98.249 v 11. 3. 2008, 09:58

2008-03-11T09:58:49Z

← Starší verze		Verze z 11. 3. 2008, 09:58
Řádek 1:		Řádek 1:
	Na několika AP (naposledy na Vláře) jsme řešili problém s dlouhým pingem při jakémkoli uploadu. Tj. symptomy typické pro [[Problém skrytých uzlů („hidden nodes“) \| Problém skrytých uzlů]].		Na několika AP (naposledy na Vláře) jsme řešili problém s dlouhým pingem při jakémkoli uploadu. Tj. symptomy typické pro [[Problém skrytých uzlů („hidden nodes“) \| Problém skrytých uzlů]].

	Pokud si ~~chcete~~ s tímto problémem vyhrát, ~~musíte jej nejdříve~~ umět vyvolat. ~~Z linuxu je to snadné~~:		Protože AP Vlára jede na OS Mikrotik, který nepodporuje 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ší 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		nmap -np80 10.143.x.2-254
Řádek 7:		Řádek 10:
	Tento příkaz vám vypíše IP adresy všech WiFi krabiček ze zadaného rozsahu.		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. Pro to si napíšeme tento skript:		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.a/ &
Řádek 15:		Řádek 18:
	...		...

	kde 10.143.x.a, .b, .c, .d jsou IP adresy jednotlivých krabiček.		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~~ nezná, udělejte:		Pozn: Pokud příkaz ab váš Debian Linux nezná, udělejte:
	apt-get install apache2-utils		apt-get install apache2-utils

Řádek 25:		Řádek 28:
	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čí".		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í. ~~Tím~~ se maximální měrou zatíží upload APčka, a vy díky tomu můžete snadno změřit, jaká je ~~jeho~~ maximální propustnost.		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.

	~~U APček, nastavených do modu "B only"~~, to ~~může být pouze 500kbit/s (viz AP Vlára)~~ - na ~~tuto hodnotu byste proto měli nastavit horní třídu QoS! Ž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!~~		Pokud vám QoS pracuje správně, poznáte to okamžitě - pingy na uživatele začnou chodit s normálními hodnotami.

	~~Pokud vám~~ QoS ~~pracuje správně~~, ~~poznáte to okamžitě -~~ pingy ~~začnou chodit~~ tak~~, jak se patří.~~		* !!!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é!

	~~Pozor! pokud pingy ladíte z jiného APčka pingáním od sebe~~ na ~~krabičku~~, ~~nezapomeňte IP adresu krabičky přidat~~ do ~~některé QoS fronty, 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ů!

195.113.98.249 v 11. 3. 2008, 09:39

2008-03-11T09:39:28Z

← Starší verze		Verze z 11. 3. 2008, 09:39
Řádek 1:		Řádek 1:
	Na několika AP (naposledy na Vláře) jsme řešili problém s dlouhým pingem při jakémkoli uploadu. Tj. symptomy typické pro [[Problém skrytých uzlů]].		Na několika AP (naposledy na Vláře) jsme řešili problém s dlouhým pingem při jakémkoli uploadu. Tj. symptomy typické pro [[Problém skrytých uzlů („hidden nodes“) \| Problém skrytých uzlů]].

	Pokud si chcete s tímto problémem vyhrát, musíte jej nejdříve umět vyvolat. Z linuxu je to snadné:		Pokud si chcete s tímto problémem vyhrát, musíte jej nejdříve umět vyvolat. Z linuxu je to snadné:

195.113.98.249 v 11. 3. 2008, 09:38

2008-03-11T09:38:30Z

← Starší verze		Verze z 11. 3. 2008, 09:38
Řádek 1:		Řádek 1:
	Na několika AP (naposledy na Vláře) jsme řešili problém s dlouhým pingem při jakémkoli uploadu.		Na několika AP (naposledy na Vláře) jsme řešili problém s dlouhým pingem při jakémkoli uploadu. Tj. symptomy typické pro [[Problém skrytých uzlů]].

	Pokud si chcete s tímto problémem vyhrát, musíte jej nejdříve umět vyvolat. Z linuxu je to snadné:		Pokud si chcete s tímto problémem vyhrát, musíte jej nejdříve umět vyvolat. Z linuxu je to snadné:

10.143.19.19 v 10. 3. 2008, 23:40

2008-03-10T23:40:59Z

← Starší verze		Verze z 10. 3. 2008, 23:40
Řádek 27:		Řádek 27:
	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í. Tím se maximální měrou zatíží upload APčka, a vy díky tomu můžete snadno změřit, jaká je jeho maximální propustnost.		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í. Tím se maximální měrou zatíží upload APčka, a vy díky tomu můžete snadno změřit, jaká je jeho maximální propustnost.

	U APček, nastavených do modu "B only", to může být pouze 500kbit/s (viz AP Vlára) - na tuto hodnotu byste proto měli nastavit horní třídu QoS! Ž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.~~...~~		U APček, nastavených do modu "B only", to může být pouze 500kbit/s (viz AP Vlára) - na tuto hodnotu byste proto měli nastavit horní třídu QoS! Ž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!

			Pokud vám QoS pracuje správně, poznáte to okamžitě - pingy začnou chodit tak, jak se patří.

			Pozor! pokud pingy ladíte z jiného APčka pingáním od sebe na krabičku, nezapomeňte IP adresu krabičky přidat do některé QoS fronty, jinak si budete (jako já) trhat vlasy a nechápat, proč jsou ty pingy na krabičku pořád tak špatné!