Rychlost NV2
Z KHnetWiki
| Řádka 24: | Řádka 24: | ||
Výpočet je zjevně: DefaultReceiveWindow = multiply your ISPs download caps in kilobytes by 1024 then divide by 8 (jenže u přístupového bodu Jung to rozhodně neplatí). | Výpočet je zjevně: DefaultReceiveWindow = multiply your ISPs download caps in kilobytes by 1024 then divide by 8 (jenže u přístupového bodu Jung to rozhodně neplatí). | ||
| - | Při nastavování u klientů je potřeba zkoušet a tuto hodnotu nezvyšovat zbytečně. Je potřeba v několika krocích a začít na 17520. Není nutné očekávat obrovské hodnoty přenosových rychlostí, pokud se přiblíží 30Mbit/s (tedy max. download klienta na AirMax), je to v pořádku. | + | Při nastavování u klientů je potřeba zkoušet a tuto hodnotu '''nezvyšovat zbytečně'''. Je potřeba v několika krocích a začít na 17520. Není nutné očekávat obrovské hodnoty přenosových rychlostí, pokud se přiblíží 30Mbit/s (tedy max. download klienta na AirMax), je to v pořádku. Moc velká hodnota může mít vliv na aplikace, které s tím nepočítají (obecně řečeno: programátor se na to vykašlal), zvláště typy IM, VoIP, atp. |
Je též možné, že mají vliv i jiné hodnoty konfigurace TCP stacku windows (případně přímo driveru síťové karty). K nalezení v CLI příkazu ''netsh interface tcp'' Popis snad někdy dodám. Ale testovat tohle je práce na dlouhé zimní večery. | Je též možné, že mají vliv i jiné hodnoty konfigurace TCP stacku windows (případně přímo driveru síťové karty). K nalezení v CLI příkazu ''netsh interface tcp'' Popis snad někdy dodám. Ale testovat tohle je práce na dlouhé zimní večery. | ||
| - | [[ludvik]], 23.3.2013. | + | [[Uživatel:ludvik]], 23.3.2013. |
Verze z 23. 3. 2013, 00:37
Na některých spojích, především PtP (Point to Point) může být problém s přenosovou rychlostí jedné konexe. Především se to týká NV2 technologie fy Mikrotik.
Neví se zatím, co přesně to způsobuje. Jsou závislosti jak na verzi Windows ve které se to testuje, tak zjevně na verzi operačního systému Mikrotik (ROS) a také na typu HW Routerboard.
V rámci testů na RB751G (tedy 2.4GHz 802.11n) se zjistilo následující:
- Windows XP: pravděpodobně v pořádku
- Windows Vista: špatné
- Windows 7: špatné
- Windows 8: v pořádku
- Linux (a ROS): v pořádku. Jednotlivé verze jádra se ovšem testují špatně, je jich značné množství, především u čistého Linuxu.
Problém se projevuje tak, že test rychlosti na TCP spojení dá jen 10Mbit (plus mínus, ale výrazně přes 11 to nejde). Nejenom na běžných internetových měřácích (a u nás), ale i u btest.exe od Mikrotiku.
Jediné zatím nalezené řešení je změna parametru TCP Window v registrech windows. Testováno na Send straně, na Receive to bude nejspíš to samé.
Větev:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\AFD\Parameters
Hodnota DefaultSendWindow (DWORD). Je to v násobcích MSS, tedy v naprosté většině případů 1460. Testováno 64240, při této hodnotě už přenos v rámci jedné konexe dává očekávané výsledky (>40Mbit). Tento údaj tam ve výchozí instalaci není, je nutno ho přidat. Po změně je samozřejmě nutný reboot windows.
Komparativní hodnota je DefaultRecieveWindow (pozn. editora: nutno ověřit někde na microsoft.com).
Výpočet je zjevně: DefaultReceiveWindow = multiply your ISPs download caps in kilobytes by 1024 then divide by 8 (jenže u přístupového bodu Jung to rozhodně neplatí).
Při nastavování u klientů je potřeba zkoušet a tuto hodnotu nezvyšovat zbytečně. Je potřeba v několika krocích a začít na 17520. Není nutné očekávat obrovské hodnoty přenosových rychlostí, pokud se přiblíží 30Mbit/s (tedy max. download klienta na AirMax), je to v pořádku. Moc velká hodnota může mít vliv na aplikace, které s tím nepočítají (obecně řečeno: programátor se na to vykašlal), zvláště typy IM, VoIP, atp.
Je též možné, že mají vliv i jiné hodnoty konfigurace TCP stacku windows (případně přímo driveru síťové karty). K nalezení v CLI příkazu netsh interface tcp Popis snad někdy dodám. Ale testovat tohle je práce na dlouhé zimní večery.
Uživatel:ludvik, 23.3.2013.
