Propustnost 5Ghz spoje,prosím o rady

[okoun]

Soucastne 55/55Mb v TCP? Na 2x2 20MHz? Zitra se na to jedu podivat

jiste jde to, když dáš s 40MHz a tdma 2 ms 100/100

[hapi]

Soucastne 55/55Mb v TCP? Na 2x2 20MHz? Zitra se na to jedu podivat

jo to zvládne

[RaMa]

Prvni clovek, ktery mi ukaze jak prenese s dualnima antenama v Nku na 2x2 s 20MHz kanalem na vzdalenost vic jak 1km a v norme 55/55Mb (tedy 55 FD) realnych TCP dat, dostane flasku moravske domaci slivovice

Beru jen prokazatelne dukazy

[okoun]

prokazatelné důkazy? jaké například, přenos mezi dvěma pcčky? leštím si skleničky

[RaMa]

Prijedu s flaskou, na oba konce dame notebook a poslem si treba FTPckem nejake soubory proti sobe. Pro zjednoduseni muzeme pouzit i nejaky ten btest nebo NetTest.
Potom omrknu na cem to jede a pojedu si to postavit k nam.

[RaMa]

Tak kdo se predvede s tema 55Mb FD?

[hapi]

no tak dobře

[hapi]

tak výsledky.

2x20MHz, 4 TCP spojení, btest
rate 130/130Mbit


TDMA 1ms
38/38Mbit, CPU 81%

TDMA 2ms
50/50Mbit, CPU 75%

TDMA 3ms
57/57Mbit, CPU 70%

TDMA 4ms
56/56Mbit, CPU 66%



tady je krásně vydět, tak je potřeba víc spojení pro větší TDMA okno při TCP. Kdo rozumí síťařině, dojde mu to proč to tak je. Zjednodušeně řečeno, při vetšim TDMA se u TCP protokolu na jedno spojení čeká na potvrzovací pakety a TDMA rámce neodchází plně využitý. Případ TDMA 4ms kdy nejsou rámce úplně naplněný daty. Bylo by třeba pustit test z více spojeními aby se TDMA rámec celej zaplnil a věřim že by to vyšahlo na 60/60Mbit.

Upozorňuju že rate wifiny je pouze na 130Mbit. Mikrotik tuhle chybu opravil na 40MHz kanále kdy je rate plných 300Mbit ale u 20MHz to neopravil... nechápu proč. Snad se opravy dočkáme aby rate bylo 144Mbit a tim pádem i větší rychlosti a na ještě snesitelný 2ms by to dalo minimálně o 5/5Mbit víc.

Samozřejmně jsem tam mohl nahulit 20 spojení a výsledky by byly ještě lepší ale to nemá smysl.

Taky je zajímavá závislost TDMA na CPU. Čim menší TDMA, tim větší zátěž CPU. Je to logický. Stoupá režijní čas CPU pro obsluhu TDMA.

Jedno TCP spojení bohužel testnout nemůžu. Neni tam nikde rychlý železo.

Test byl prováděn na RB411, dual reflektor 23dB, vzdálenost 2km.

[net.work]

moc diky za test, mohl bych jeste poprosit, jak se Nv2 chova v zatezi v pomeru napr 70:30 ?

Dekuji

[hapi]

TDMA 1ms,
47/22Mbit, CPU 65%

TDMA 2ms,
70/22Mbit, CPU 60%

TDMA 3ms,
75/22Mbit, CPU 55% - nestíhají generovat RBčka

TDMA 4ms,
70/22Mbit, CPU 50% - nestíhají generovat RBčka

stejný test, jenom jsem omezil upload na 20Mbit a download nechal bejt.

-------------------------------------------------------------------------------------------------------------

TDMA 1ms,
70/2Mbit, CPU 65%

TDMA 2ms,
97/2Mbit, CPU 60% - hranice ethernetu

TDMA 3ms,
97/2Mbit, CPU 55% - hranice ethernetu

TDMA 4ms,
97/2Mbit, CPU 50% - hranice ethernetu

stejný test, pouze download.

[hapi]

TDMA 1ms dost nehospodárně zachází s datovym tokem, to je hned vidět, za to ale dosahuje nejnižších latencí což je o polovinu menší než na 2ms. Záleží na každym kde to použije. Na ptmp neni problem nasadit 2ms pro zvýšení efektivnosti využití NV2ky, tam se to dá kousnout. Ovšem pokud máte za sebou 4x ptp spoje na NV2, tak tam už se člověk o tu latenci zajímá a vidí jak roste nahoru a raději tam dá 1ms. Ona ta latence na NV2 vypadá hrozivě ale podle mejch testů tak od cca 20% zatížení (hodně záleží na rate), se NV2 na latenci vyplácí víc než nstreme. Defakto u NV2 vzroste latence při zátěži jenom neznatelně ale nstreme i když má ze začátku latenci menší, s roustoucí zátěží latence stoupá nad latenci NV2 a navíc dost kolísá a jsou tam občas špičky. NV2 je na tohle podstatně líp. My jsme musely dát na všechny nový mimo 2x2 spoje NV2 protože nstreme i když jel dobře, po čase se prostě rychlostí zasek někde dole a odmítal propustit víc. NV2 zatim tohle neudělala. Asi pujde o rozdíl mezi 2x2 a 1x1. U známejch co maji 1x1 nstreme jede ok bez vedlejších efektů. Na 2x2 jsem s tim měl po čase vždy problem na jakymkoliv HW (alix, rb411, sxt).

Pro příklad, latence přes 4x ptp nv2 spoje na 1ms je 10-13ms. Je to hodně? málo? tahle latence tam drží i když tam něco teče případně jde o cca 2-3ms vejš.

Cesta pingu je skrz: linux, gw, switch, orcave 100Mbit, rb450g, switch, alix - alix, switch, rb411 - rb411, switch, sxt - sxt, switch, sxt - sxt, switch, linux. Co RBčko(sxt,rb411,alix), to routing.

Kód: Vybrat vše

traceroute to 10.247.0.250 (10.247.0.250), 30 hops max, 60 byte packets
 1  gw.skylan.cz (192.168.1.2)  0.207 ms  0.159 ms  0.168 ms
 2  10.255.0.2 (10.255.0.2)  0.730 ms  0.730 ms  0.723 ms
 3  10.255.255.2 (10.255.255.2)  3.389 ms  3.361 ms  3.368 ms
 4  10.255.1.6 (10.255.1.6)  3.361 ms  3.199 ms  3.274 ms
 5  10.255.255.14 (10.255.255.14)  8.233 ms  8.187 ms  8.204 ms
 6  10.252.0.3 (10.252.0.3)  8.165 ms  7.208 ms  7.283 ms
 7  10.255.255.18 (10.255.255.18)  11.253 ms  10.827 ms  10.807 ms
 8  10.248.0.4 (10.248.0.4)  10.791 ms  8.432 ms  8.409 ms
 9  10.255.255.26 (10.255.255.26)  12.376 ms  12.360 ms  12.342 ms
10  10.247.0.250 (10.247.0.250)  12.308 ms  10.525 ms  10.528 ms


[net.work]

moc dik za testy - tech 100Mbit HD je docela hukot, to sem necekal (v UDP mozna, v TCP urcite ne)...

[okoun]

sry, ale latence 3 skoky 13 ms je pro mě dost, počkám až se opraví ten bug a nebo až opravějí ten nstreme, snad se dočkám

[pcwifi]

jaj, co bych za to dal, kdybych mel tak krasnou odezvu vymenim RB433 za 711 v nejlbizsi dobe a jestli bude odezva stale v hajzlu, tak uz jedine antena...protoze vic uz neni co menit...

PW

[hapi]

jo ale ty latence tam jsou pořád, i v zátěži. Jitter je lepší, spolehlivost větší. To jsou faktory na který lidi zapomínaji a furt jenom koukaji na latenci. Jako nejsem tu od toho abych to někomu rozmlouval to ne, ale větší latence neznamená horší linka. Horší linka je spíš špatnej jitter, to podle mě hraje větší roly. Přes 4 spoje je 13ms docela v pohodě ale když skrz všechny teče ftpčko nějakých 60-70Mbit tak jsem v klidu.

Odezva 13ms trochu naštve, to jo, když si vemu že nstreme dosahne na těch spojích nějaký 4ms. Hold časy se mění. U starších canopkách se nikdo nedivil 20ms na spoji. Nový nevim kolik maji ale tušim že to zázračný taky neni ale TDMA jsme všichni chtěly ne? Tak tady ho máme.

Je fakt že by mikrotik mohl nějak pořešit latence na ptp spojích a zavést na nich nějaký dynamicky měnící se čas jenomže to by jsme se vrátily zpět k nstreme a měnicím se latencím se zátěží.