Problém skrytých uzlů („hidden nodes“) - Historie editací

10.143.19.19: /* Závislost propustnosti na zatížení sítě a hodnotě RTS Threshold pro velké packety */

2008-03-28T00:43:24Z

Závislost propustnosti na zatížení sítě a hodnotě RTS Threshold pro velké packety

← Starší verze		Verze z 28. 3. 2008, 00:43
Řádek 30:		Řádek 30:
	[[Soubor:Propustnost-vs-RT-Lambda.png]]		[[Soubor:Propustnost-vs-RT-Lambda.png]]

	Figure 6: Tady vidíte, jak se chová propustnost AP s 25 klienty, kteří posílají packety o průměrné velikosti 1000 bajtů, v závislosti na RTS Threshold a míře zátěže λ, generované klienty.		Figure 6: Tady vidíte, jak se chová propustnost AP s 25 klienty, kteří posílají packety o průměrné velikosti 1000 bajtů, v závislosti na RTS Threshold a míře zátěže λ, generované klienty. Bohužel v práci není uvedeno, jaká část klientů (či jestli vůbec nějací) jsou skryté uzly.
	* Pro velmi nízkou zátěž λ=0.0001 je propustnost AP = 50% maximální reálné propustnosti, nastavení RTS Threshold nemá vůbec žádný vliv, protože nenastávají kolize		* Pro velmi nízkou zátěž λ=0.0001 je propustnost AP = 50% maximální reálné propustnosti, nastavení RTS Threshold nemá vůbec žádný vliv, protože nenastávají kolize
	* Pro větší zátěž λ>=0.0002 ale už má nastavení RTS Thresholdu podstatný vliv na propustnost. Pokud necháte RTS Threshold v defaultní hodnotě (2000 bajtů), je propustnost pouze 48% maximální reálné propustnosti. Pokud nastavíte RTS Threshold na optimální hodnotu (např. 170 bajtů), dostanete propustnost až 75%!!		* Pro větší zátěž λ>=0.0002 ale už má nastavení RTS Thresholdu podstatný vliv na propustnost. Pokud necháte RTS Threshold v defaultní hodnotě (2000 bajtů), je propustnost pouze 48% maximální reálné propustnosti. Pokud nastavíte RTS Threshold na optimální hodnotu (např. 170 bajtů), dostanete propustnost až 75%!!

10.143.19.19: /* Chování sítě v závislosti na nastavení RTS Threshold */

2008-03-28T00:41:23Z

Chování sítě v závislosti na nastavení RTS Threshold

← Starší verze		Verze z 28. 3. 2008, 00:41
Řádek 23:		Řádek 23:

	== Chování sítě v závislosti na nastavení RTS Threshold ==		== Chování sítě v závislosti na nastavení RTS Threshold ==
	Zatím ~~nejlepší~~ článek, popisující chování WiFi APčka v závislosti na provozu, počtu připojených lidí ~~a nastavení RTS Threshold~~ je k dispozici zde: http://www2.tku.edu.tw/~tkjse/6-1/6-1-8.pdf		Zatím jediný článek, popisující chování WiFi APčka v závislosti na nastavení RTS Threshold, na provozu a na počtu připojených lidí je k dispozici zde: http://www2.tku.edu.tw/~tkjse/6-1/6-1-8.pdf

	Dovolím si vypůjčit a česky okomentovat několik obrázků z tohoto článku:		Dovolím si vypůjčit a česky okomentovat několik obrázků z tohoto článku:

10.143.19.19: /* Úvod (polopatický) */

2008-03-28T00:39:26Z

Úvod (polopatický)

← Starší verze		Verze z 28. 3. 2008, 00:39
Řádek 7:		Řádek 7:
	** v případě bezdrátových karet vyžaduje znalé a zodpovědné uživatele, kteří jsou schopni nastavení RTS Threshold obnovit i v případě reinstalace operačního systému		** v případě bezdrátových karet vyžaduje znalé a zodpovědné uživatele, kteří jsou schopni nastavení RTS Threshold obnovit i v případě reinstalace operačního systému
	** ve srovnání s ideálním stavem - sítí s žádnými skrytými uzly - čekání na potvrzení CTS způsobuje pokles propustnosti sítě		** ve srovnání s ideálním stavem - sítí s žádnými skrytými uzly - čekání na potvrzení CTS způsobuje pokles propustnosti sítě
	** pokud bude většina uživatelů v síti používat RTS/CTS, pak uživatel, který ~~tento~~ mechanismus nemá nastaven, bude nad ostatními uživateli ve výhodě – bude schopen data přenášet rychleji a ~~častěji~~		** pokud bude většina uživatelů v síti používat RTS/CTS, pak uživatel, který není skrytým uzlem a mechanismus RTS/CTS nemá nastaven, bude nad ostatními uživateli ve výhodě – bude schopen data přenášet o něco rychleji, protože nebude čekat na CTS. Defaultní nastavení RTS/CTS je totiž takové, že karta pro packety menší než "RTS Threshold" (defaultně 2000 bajtů) sice vyšle RTS, ale sami si ihned odpoví "Clear to send" a začne vysílat data.
	** některé přístupové body (Mikrotik!!!!) tento mechanismus nepodporují nebo podporují chybně		** některé přístupové body (Mikrotik!!!!) tento mechanismus nepodporují nebo podporují chybně

10.143.19.19: /* Úvod */

2008-03-28T00:33:48Z

Úvod

← Starší verze		Verze z 28. 3. 2008, 00:33
Řádek 1:		Řádek 1:
	== Úvod ==		== Úvod (polopatický) ==
	Tento problém je způsoben faktem, že návrh fyzických protokolů 802.11a/b/g (WiFi) byl veden hlavním předpokládaným způsobem využití bezdrátovým připojením uživatelů uvnitř budov na vzdálenost maximálně desítek metrů, jako doplněk k metalické síťové kabeláži. Typický příklad je připojení desítek notebooků účastníků konference v sále, kde by připojení pomocí kabelů bylo neekonomické, nepraktické a velmi těžko realizovatelné.		Tento problém je způsoben faktem, že návrh fyzických protokolů 802.11a/b/g (WiFi) byl veden hlavním předpokládaným způsobem využití bezdrátovým připojením uživatelů uvnitř budov na vzdálenost maximálně desítek metrů, jako doplněk k metalické síťové kabeláži. Typický příklad je připojení desítek notebooků účastníků konference v sále, kde by připojení pomocí kabelů bylo neekonomické, nepraktické a velmi těžko realizovatelné.
	*Rozdíl mezi konferenčním sálem a WiFi sítí s externími anténami (na střechách) je ten, že wifi karty všech uživatelů v sále vzhledem k malé vzdálenosti a všesměrovým anténám vzájemně slyší své vysílání. Mohou tak reagovat na stav, kdy před vysíláním vlastních dat zjistí, že kanál je momentálně obsazen vysíláním jiného uživatele.		*Rozdíl mezi konferenčním sálem a WiFi sítí s externími anténami (na střechách) je ten, že wifi karty všech uživatelů v sále vzhledem k malé vzdálenosti a všesměrovým anténám vzájemně slyší své vysílání. Mohou tak reagovat na stav, kdy před vysíláním vlastních dat zjistí, že kanál je momentálně obsazen vysíláním jiného uživatele.

Dulik: /* Řešení */

2008-03-27T22:39:36Z

Řešení

← Starší verze		Verze z 27. 3. 2008, 22:39
Řádek 63:		Řádek 63:
	* Pokud je RTS/CTS vypnut (tj. RT=nekonečno), pak od průměrné velikosti packetů = 1000 bajtů začnou kolize snižovat propustnost		* Pokud je RTS/CTS vypnut (tj. RT=nekonečno), pak od průměrné velikosti packetů = 1000 bajtů začnou kolize snižovat propustnost

	==Řešení==		==Řešení skrytých uzlů v síti==
	* Jak navrhují autoři těchto grafů (Fun Ye, Shiann-Tsong Sheu, Tobias Chen a Jenhui Chen), nastavení RTS Thresholdu na nízkou hodnotu (např. 175) prudce zlepší chování ~~celé~~ sítě		* Jak navrhují autoři těchto grafů (Fun Ye, Shiann-Tsong Sheu, Tobias Chen a Jenhui Chen), nastavení RTS Thresholdu na nízkou hodnotu (např. 175) prudce zlepší chování sítě
	* Bohužel Mikrotik nepodporuje mechanismus RTS/CTS - pokud jej u klienta aktivujete, Mikrotik mu nikdy nepošle CTS, takže takový klient přestane vysílat.		* Bohužel Mikrotik nepodporuje mechanismus RTS/CTS - pokud jej u klienta aktivujete, Mikrotik mu nikdy nepošle CTS, takže takový klient přestane vysílat.
	* Na Mikrotiku se tedy musíte smířit s tím, že s rostoucím počtem klientů bude dramaticky klesat propustnost uploadu - minimálně tak, jak to znázorňuje Figure 9. S tímto vědomím [[Probl%C3%A9m_s_velk%C3%BDm_pingem\|musíte nastavit i Qosy v Mikrotiku (viz návod)]], aby klientům, kteří jsou skryté uzly, jela síť vůbec nějak.		* Na Mikrotiku se tedy musíte smířit s tím, že s rostoucím počtem klientů bude dramaticky klesat propustnost uploadu - minimálně tak, jak to znázorňuje Figure 9. S tímto vědomím [[Probl%C3%A9m_s_velk%C3%BDm_pingem\|musíte nastavit i Qosy v Mikrotiku (viz návod)]], aby klientům, kteří jsou skryté uzly, jela síť vůbec nějak.
	* Ideální řešení je místo Mikrotiku nasadit Linux, jehož Madwifi samozřejmě RTS/CTS podporuje. Návod na instalaci [http://wiki.hkfree.org/RouterboardRB500Linux Linuxu na RB532 je zde]		* Ideální řešení je místo Mikrotiku nasadit Linux, jehož Madwifi samozřejmě RTS/CTS podporuje. Návod na instalaci [http://wiki.hkfree.org/RouterboardRB500Linux Linuxu na RB532 je zde]

Dulik: /* Chování sítě v závislosti na nastavení RTS Threshold */

2008-03-27T22:35:14Z

Chování sítě v závislosti na nastavení RTS Threshold

@@ Řádek 9: / Řádek 9: @@
 **	pokud bude většina uživatelů v síti používat RTS/CTS, pak uživatel, který tento mechanismus nemá nastaven, bude nad ostatními uživateli ve výhodě – bude schopen data přenášet rychleji a častěji
 **	některé přístupové body (Mikrotik!!!!) tento mechanismus nepodporují nebo podporují chybně
 == Chování sítě v závislosti na nastavení RTS Threshold ==

Dulik: /* Úvod */

2008-03-27T22:08:15Z

Úvod

← Starší verze		Verze z 27. 3. 2008, 22:08
Řádek 6:		Řádek 6:
	*Omezení efektu skrytých uzlů je možné pouze dodržování minimálních vzdáleností uživatelů od přístupového bodu (do 100m) a použitím máloziskových antén s větším úhlem vyzařování, které zajistí, že se většina uživatelů bude vzájemně slyšet. Pokud takovouto konfiguraci nelze docílit, je ještě možné nastavit všem uživatelům daného přístupového bodu povinné používání mechanismu RTS/CTS, kdy každé zařízení musí před vysláním regulérního packetu poslat požadavek RTS („Request to send“) a čekat na odpověď přístupového bodu CTS („Clear to send“). Tento mechanismus omezuje kolize (Collision Avoidance, CSMA/CA), bohužel jej ale nelze zapnout centrálně, musí se nastavit u každého uživatele zvlášť parametrem „RTS Threshold“, který určuje velikost packetu, před jehož vysláním se má čekat na CTS. Nevýhody používání mechanismu RTS/CTS jsou následující:		*Omezení efektu skrytých uzlů je možné pouze dodržování minimálních vzdáleností uživatelů od přístupového bodu (do 100m) a použitím máloziskových antén s větším úhlem vyzařování, které zajistí, že se většina uživatelů bude vzájemně slyšet. Pokud takovouto konfiguraci nelze docílit, je ještě možné nastavit všem uživatelům daného přístupového bodu povinné používání mechanismu RTS/CTS, kdy každé zařízení musí před vysláním regulérního packetu poslat požadavek RTS („Request to send“) a čekat na odpověď přístupového bodu CTS („Clear to send“). Tento mechanismus omezuje kolize (Collision Avoidance, CSMA/CA), bohužel jej ale nelze zapnout centrálně, musí se nastavit u každého uživatele zvlášť parametrem „RTS Threshold“, který určuje velikost packetu, před jehož vysláním se má čekat na CTS. Nevýhody používání mechanismu RTS/CTS jsou následující:
	** v případě bezdrátových karet vyžaduje znalé a zodpovědné uživatele, kteří jsou schopni nastavení RTS Threshold obnovit i v případě reinstalace operačního systému		** v případě bezdrátových karet vyžaduje znalé a zodpovědné uživatele, kteří jsou schopni nastavení RTS Threshold obnovit i v případě reinstalace operačního systému
	** čekání na potvrzení CTS způsobuje ~~nárust režie a tedy~~ pokles propustnosti sítě		** ve srovnání s ideálním stavem - sítí s žádnými skrytými uzly - čekání na potvrzení CTS způsobuje pokles propustnosti sítě
	** pokud bude většina uživatelů v síti používat RTS/CTS, pak uživatel, který tento mechanismus nemá nastaven, bude nad ostatními uživateli ve výhodě – bude schopen data přenášet rychleji a častěji		** pokud bude většina uživatelů v síti používat RTS/CTS, pak uživatel, který tento mechanismus nemá nastaven, bude nad ostatními uživateli ve výhodě – bude schopen data přenášet rychleji a častěji
	** některé přístupové body (Mikrotik!!!!) tento mechanismus nepodporují nebo podporují chybně		** některé přístupové body (Mikrotik!!!!) tento mechanismus nepodporují nebo podporují chybně

195.178.89.175: /* Řešení */

2008-03-11T12:43:08Z

Řešení

← Starší verze		Verze z 11. 3. 2008, 12:43
Řádek 55:		Řádek 55:
	* Bohužel Mikrotik nepodporuje mechanismus RTS/CTS - pokud jej u klienta aktivujete, Mikrotik mu nikdy nepošle CTS, takže takový klient přestane vysílat.		* Bohužel Mikrotik nepodporuje mechanismus RTS/CTS - pokud jej u klienta aktivujete, Mikrotik mu nikdy nepošle CTS, takže takový klient přestane vysílat.
	* Na Mikrotiku se tedy musíte smířit s tím, že s rostoucím počtem klientů bude dramaticky klesat propustnost uploadu - minimálně tak, jak to znázorňuje Figure 9. S tímto vědomím [[Probl%C3%A9m_s_velk%C3%BDm_pingem\|musíte nastavit i Qosy v Mikrotiku (viz návod)]], aby klientům, kteří jsou skryté uzly, jela síť vůbec nějak.		* Na Mikrotiku se tedy musíte smířit s tím, že s rostoucím počtem klientů bude dramaticky klesat propustnost uploadu - minimálně tak, jak to znázorňuje Figure 9. S tímto vědomím [[Probl%C3%A9m_s_velk%C3%BDm_pingem\|musíte nastavit i Qosy v Mikrotiku (viz návod)]], aby klientům, kteří jsou skryté uzly, jela síť vůbec nějak.
	* Ideální řešení je místo Mikrotiku nasadit Linux, jehož Madwifi samozřejmě RTS/CTS podporuje. Návod na instalaci		* Ideální řešení je místo Mikrotiku nasadit Linux, jehož Madwifi samozřejmě RTS/CTS podporuje. Návod na instalaci [http://wiki.hkfree.org/RouterboardRB500Linux Linuxu na RB532 je zde]
	[http://wiki.hkfree.org/RouterboardRB500Linux Linuxu na RB532 je zde]

195.178.89.175: /* Řešení */

2008-03-11T12:42:55Z

Řešení

← Starší verze		Verze z 11. 3. 2008, 12:42
Řádek 55:		Řádek 55:
	* Bohužel Mikrotik nepodporuje mechanismus RTS/CTS - pokud jej u klienta aktivujete, Mikrotik mu nikdy nepošle CTS, takže takový klient přestane vysílat.		* Bohužel Mikrotik nepodporuje mechanismus RTS/CTS - pokud jej u klienta aktivujete, Mikrotik mu nikdy nepošle CTS, takže takový klient přestane vysílat.
	* Na Mikrotiku se tedy musíte smířit s tím, že s rostoucím počtem klientů bude dramaticky klesat propustnost uploadu - minimálně tak, jak to znázorňuje Figure 9. S tímto vědomím [[Probl%C3%A9m_s_velk%C3%BDm_pingem\|musíte nastavit i Qosy v Mikrotiku (viz návod)]], aby klientům, kteří jsou skryté uzly, jela síť vůbec nějak.		* Na Mikrotiku se tedy musíte smířit s tím, že s rostoucím počtem klientů bude dramaticky klesat propustnost uploadu - minimálně tak, jak to znázorňuje Figure 9. S tímto vědomím [[Probl%C3%A9m_s_velk%C3%BDm_pingem\|musíte nastavit i Qosy v Mikrotiku (viz návod)]], aby klientům, kteří jsou skryté uzly, jela síť vůbec nějak.
	* Ideální řešení je místo Mikrotiku nasadit Linux, jehož Madwifi samozřejmě RTS/CTS podporuje		* Ideální řešení je místo Mikrotiku nasadit Linux, jehož Madwifi samozřejmě RTS/CTS podporuje. Návod na instalaci
			[http://wiki.hkfree.org/RouterboardRB500Linux Linuxu na RB532 je zde]

195.178.89.175: /* Řešení */

2008-03-11T12:30:31Z

Řešení

← Starší verze		Verze z 11. 3. 2008, 12:30
Řádek 54:		Řádek 54:
	* Jak navrhují autoři těchto grafů (Fun Ye, Shiann-Tsong Sheu, Tobias Chen a Jenhui Chen), nastavení RTS Thresholdu na nízkou hodnotu (např. 175) prudce zlepší chování celé sítě		* Jak navrhují autoři těchto grafů (Fun Ye, Shiann-Tsong Sheu, Tobias Chen a Jenhui Chen), nastavení RTS Thresholdu na nízkou hodnotu (např. 175) prudce zlepší chování celé sítě
	* Bohužel Mikrotik nepodporuje mechanismus RTS/CTS - pokud jej u klienta aktivujete, Mikrotik mu nikdy nepošle CTS, takže takový klient přestane vysílat.		* Bohužel Mikrotik nepodporuje mechanismus RTS/CTS - pokud jej u klienta aktivujete, Mikrotik mu nikdy nepošle CTS, takže takový klient přestane vysílat.
	* Na Mikrotiku se tedy musíte smířit s tím, že s rostoucím počtem klientů bude dramaticky klesat propustnost uploadu - minimálně tak, jak to znázorňuje Figure 9. S tímto vědomím [[Probl%C3%A9m_s_velk%C3%BDm_pingem musíte\|nastavit i Qosy]], aby klientům, kteří jsou skryté uzly, jela síť vůbec nějak.		* Na Mikrotiku se tedy musíte smířit s tím, že s rostoucím počtem klientů bude dramaticky klesat propustnost uploadu - minimálně tak, jak to znázorňuje Figure 9. S tímto vědomím [[Probl%C3%A9m_s_velk%C3%BDm_pingem\|musíte nastavit i Qosy v Mikrotiku (viz návod)]], aby klientům, kteří jsou skryté uzly, jela síť vůbec nějak.
	* Ideální řešení je místo Mikrotiku nasadit Linux, jehož Madwifi samozřejmě RTS/CTS podporuje		* Ideální řešení je místo Mikrotiku nasadit Linux, jehož Madwifi samozřejmě RTS/CTS podporuje