Zamyšlení - Více hopů na 5GHz

[Spreamer]

Dobrý den všem,

s ohledem na stále vyšší nároky na přenosové rychlosti jsem vysledoval jeden jev, který si nedokážu nijak vysvětlit a bude to asi spíš otázka na odborníky. Níže uvedu jednoduchou modelové zapojení, které je vcelku běžné. Čili máme přivedenou konektivitu do vzdálenější lokality. Na všech spojích nanobridge lze přenést reálně 60/80 Mb/s (TCP bandwidth test, měřeno vždy mezi router č.1 a č.2, router č.2 a č.3 atd). Nanobridge jsou v režimu bridge, routováno vždy na mikrotiku. Situace:

ROUTER RB433AH č.1 -- PTP NANOBRIDGE č.1 -- ROUTER RB433AH č.2 -- PTP NANOBRIDGE č.2 -- ROUTER RB433AH č.3 -- PTP NANOBRIDGE č.3 -- ROUTER RB433AH č.4

Proč z routeru č.1 na router č.4 přenesu pouze 20-30 Mb/s, když všechny rádiový trasy maji propustnost reálně již uvedených 60-80 Mb/s? Setkal se s tím někdo? Nanobridge je hračka, tam toho nastavení moc není, zkoušel jsem laborovat, asi to bude spíše věc mikrotiku. testy jsem prováděl, když byl minimální provoz do 5 Mb/s. Myslím, že výkon RB na to má, aby takový provoz teoreaticky zvládnul, samozřejmě nárazově, ne dlouhodobě, na to jsou jiné spoje. Prosím o věcné rady (niliv příspěvky typu nanobridge je sh*t, dej tam něco jiného).

Děkuji Vám.

[hapi]

tcp window size? s roustoucí latencí klesá propustnost? vsadim se že když navíšíš počet spojení v testu tak tam těch 60Mbit projde. To neni věc hardware ale software.

[sub_zero]

jak píše Hapi, čím víc mašin, tím větší problém. Pokud by jsi to měl čistě na L2 (např 6 switchů za sebou), nemělo by být zpomalení tak znatelný, jako u L3. Každopádně... co zkusit postavit nějakej tunel přes všechny ty mašinym - tzn. z routeru č.1 až na router č.4 ? Tohle je jen můj tip, jak to otestovat, ale v praxi jsme se k tomu nikdy nedostali.

[Walkeer]

neni to ruseni mezi spoji? kdyz meris pouze jeden spoj, tak ostatni nevysilaji a nerusi....kdyz to pustis pres vsechny tak se muzou rusit navzajem.

tcp window size? s roustoucí latencí klesá propustnost? vsadim se že když navíšíš počet spojení v testu tak tam těch 60Mbit projde. To neni věc hardware ale software.

to se mi nezda, moderni OS jako win7 ci linux nastavuji window size dynamicky... Ale napr. XPcka to neumi.

[sub_zero]

to se mi nezda, moderni OS jako win7 ci linux nastavuji window size dynamicky... Ale napr. XPcka to neumi.

Nééé, nezačínejme zase tuhle utopistickou diskuzi, kterých je na toto téma na fórku plno.. Je sice krásný, že MS píše, že WIN 7 si nastavuje size automaticky, ale rozhodně to není 100%. Doporučuju si spustit na tech Win7 TCPOptimizer a nechat udělat (byť jen automatickou optimalizaci IP stacku). V 9 z 10 případů poznáte rozdíl. Někdy záleží i na typu chipu na kartě, co vše se může ovlivnit.
Já (a myslím že i Standa může napsat) jsme toto téma řešili x dnů, možná týdnů a to vč. podpory ze strany carrierů a i když úžasnej Wireshark psal, že TCP windows size je na automatiku a povolený, vždy se výsledná rychlost odvíjela od RTT, což by měl Windows Size řešit, ne? Tak kde je tedy ten problém

[Walkeer]

to se mi nezda, moderni OS jako win7 ci linux nastavuji window size dynamicky... Ale napr. XPcka to neumi.

Nééé, nezačínejme zase tuhle utopistickou diskuzi, kterých je na toto téma na fórku plno.. Je sice krásný, že MS píše, že WIN 7 si nastavuje size automaticky, ale rozhodně to není 100%. Doporučuju si spustit na tech Win7 TCPOptimizer a nechat udělat (byť jen automatickou optimalizaci IP stacku). V 9 z 10 případů poznáte rozdíl. Někdy záleží i na typu chipu na kartě, co vše se může ovlivnit.
Já (a myslím že i Standa může napsat) jsme toto téma řešili x dnů, možná týdnů a to vč. podpory ze strany carrierů a i když úžasnej Wireshark psal, že TCP windows size je na automatiku a povolený, vždy se výsledná rychlost odvíjela od RTT, což by měl Windows Size řešit, ne? Tak kde je tedy ten problém

Nerikam, ze to delaji idelane, ale asi to tezko zpusobi takto znatelny rozdil...

[Spreamer]

tcp window size? s roustoucí latencí klesá propustnost? vsadim se že když navíšíš počet spojení v testu tak tam těch 60Mbit projde. To neni věc hardware ale software.

Ano, pokud zvýším počet spojení řekněme na 30-40, dostanu navíc 10-15 Mb/s. Pokud je to SW záležitost, jak se dá řešit změnou SW nastavení? Pokud zde hraje počet spojení, tak je z pohledu zákazníka problém, protože pokud vím, tak speedmetry vytváření jedno spojení při testu a je tedy jasné, že zákazník měří nízké hodnoty. Takže řešením by teoreticky byla síť postavená na switchech nebo v mém případě zredukovat počet hopů? Měření jsem prováděl vždy přímo z winboxu, nikoliv btext utilitou z win7.

[hapi]

jak píše Hapi, čím víc mašin, tím větší problém. Pokud by jsi to měl čistě na L2 (např 6 switchů za sebou), nemělo by být zpomalení tak znatelný, jako u L3. Každopádně... co zkusit postavit nějakej tunel přes všechny ty mašinym - tzn. z routeru č.1 až na router č.4 ? Tohle je jen můj tip, jak to otestovat, ale v praxi jsme se k tomu nikdy nedostali.

počket to asi ne, ne? nejde o to jestli to je L2 nebo L3 ale jde o celkovou latenci na trase. To že to převede bridge nebo router (schválně neuvádim switch protože na wifi switch neni) by mělo bejt úplně fuk. HW switch nebo profy L3 switch by měly podat přece stejné výkony na trase se stejnými latencemi. Pokud budou stejný latence na jakýkoliv infrastruktuře tak by měla být i stejná propustnost TCP přece, ne? Latence mezi MK bridge a MK routingem musí být přeci logicky stejné když to beztak musí projít přes cpu a zpracovat klasicky kernelem. Jo jistě, bridge nemá conn. tracking defaultně zapnutej takže má o něco menší latenci ale to jde přece u routingu vypnout a jsme na tom výkonově i latenčně stejně.

Ale asi by měl tazatel zkusit zatížit sousedící spoje na max a zjistit jestli se neovlivňují. Co tudy prohnat UDP? spousta lidí sice píše že UDP neni vypovídající ale tim aspoň zjistíš jestli je možný trasou fyzicky tolik protlačit.

[Spreamer]

jak píše Hapi, čím víc mašin, tím větší problém. Pokud by jsi to měl čistě na L2 (např 6 switchů za sebou), nemělo by být zpomalení tak znatelný, jako u L3. Každopádně... co zkusit postavit nějakej tunel přes všechny ty mašinym - tzn. z routeru č.1 až na router č.4 ? Tohle je jen můj tip, jak to otestovat, ale v praxi jsme se k tomu nikdy nedostali.

počket to asi ne, ne? nejde o to jestli to je L2 nebo L3 ale jde o celkovou latenci na trase. To že to převede bridge nebo router (schválně neuvádim switch protože na wifi switch neni) by mělo bejt úplně fuk. HW switch nebo profy L3 switch by měly podat přece stejné výkony na trase se stejnými latencemi. Pokud budou stejný latence na jakýkoliv infrastruktuře tak by měla být i stejná propustnost TCP přece, ne? Latence mezi MK bridge a MK routingem musí být přeci logicky stejné když to beztak musí projít přes cpu a zpracovat klasicky kernelem. Jo jistě, bridge nemá conn. tracking defaultně zapnutej takže má o něco menší latenci ale to jde přece u routingu vypnout a jsme na tom výkonově i latenčně stejně.

Ale asi by měl tazatel zkusit zatížit sousedící spoje na max a zjistit jestli se neovlivňují. Co tudy prohnat UDP? spousta lidí sice píše že UDP neni vypovídající ale tim aspoň zjistíš jestli je možný trasou fyzicky tolik protlačit.

Jasně no, na obou spojích jsem pustil současně UDP test, následně jeden vypnul a druhý test běžel pořad stejnou rychlostí, obráceně taky OK, takže se spoje rádiově neovlivňují. Pokud přidám více spojení než 20 (např 40, tak je přenosová rychlost vyšší, ale pořád to nejede nadoraz). Zjistil jsem, že hlavní brzda je na počátku trasy, čili mezi router č.1 (GW, optika) a router č.2. Tato linka TCP testem dává 90 Mb/s (170 Mb/s UDP). Tato trasa vlastně není postavená nanobridge (špatně jsem uvedl, omlouvám se), ale na RB433AH s duálním Jirousem a nv2. k routeru č.3 je již PTP na nanobridge. K tomuto routeru č.3 již dostanu maximálně 30-40 Mb/s (přitom tato PTP trasa umí těch 60 Mb/s TCP). Ta nv2 trasa běžela na ROS 5.13, dnes jsem zkoušel update na 5.20, pořád stejný výsledek. Zdá se mi, že nv2 je celý problém, resp. problém je někde na úrovní předávání packetů LAN- >WLAN přímo v tom RB, asi na úrovní SW, ale to je mimo mé znalosti:(

[okoun]

mimochodem neřekl bych že speedtest dává jedno spojení, zkusil jsem speedtest, z toho jsem dostal 35Mb/s cca 6 hopů, nv2+nstreamy na některých hopech. no a když spustím tcp test s jedním spojením tak to ukazuje nějakých 5,6,7Mb/s což je děsný, ale v reálném provozu jsem spokojen.

[hapi]

to okoun: speedtest dává počet spojení podle potřeby. Někde u nich na webu je to popsaný jak řadí počet spojení. Defakto co si pamatuju je to, že před samotným měřením započte malej rychlostí testík podle kterýho určí kolik spojení dá na hlavní test.

to Spreamer: haha vida, další člověk kterej má nejspíš s NV2 viditelný problem. To je jako u nás když zákazník na náš speedtest v síti dá rychlost 6Mbit a na speedtest do prahy 20Mbit... jak je to možný? ale co bylo divnější že když jsem to u zákazníka spustil z ubuntu tak tam bylo krásných 30Mbit jen to fiklo. Jak je to možný? já nevim... dojebanej tcp stack ve woknech?

TCP testu v mikrotiku moc nevěř.

[mvh]

Panove teto jev pozoruji taky a dela to NV2 respektive TDMA. Schvalne tu NV2 prepni na nstream a uvidis. Tento jev je nejvic videt kdyz se retezi vice spoju s TDMA za sebou. jeden je vpoho, druhej schodi rychlost v jednom vlakne, treti i ve vice vcetne UDP. Overeno nekolika tydnu provozu (testovano na lidech

[net.work]

ano, ale za tento jev nemuze NV2, ale latence, jak jiz psali kolegove vyse...

[stepan.benes]

Proboha, zapomeňte na problémy TCP-window, tenhle nesmysl tady začal šířit Klíma, kterej k němu přišel pán Bůh v kde a šíří se to jak lavina, v příspěvcích je víc doměnek než skutečných faktů. Windows používají již drahnou dobu implementaci TCP/IP stacku z OpenBSD, která patří mezi nejlepší. Svoje problémy maj, ale ty leží trochu někde jinde. Na to aby člověk dokázal nějak rozumně odpovědět na otázku je tady moc málo informací. Můžeš sem hodit konfigurace jednotlivých prvků ? Měření nikdy neprováděj z routerů, změř trasu z nějakého stroje na na další.

[mvh]

Takze za to muze NV2
Kazdopadne je to jednoducha rovnice, NV2 lze na ceste ke klientovi pouzit smysluplne pouze jednou, logicky na last mile.