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

[Majklik]

Že je to chyba mikrotiku platí jen pro ten btest.
Jinak obecně, když zkoušíte to jedno TCP spojení (btestem) mezi vícero RBčky za sebou, tak testujte i pomocí UDP. Pokud v UDP vám to dá co čekáte (např neruší se ty dvě rádiové linky zřetězené za sebou atd), tak linky jako takové jsou v pořádku. Pokud následně TCP jde hodně dolů, tak prvně předpokládám koukáte, zda to nestojí na přetíženém CPU a pak jde už o to, že se neumí TCP btest s danou linkou vyrovnat.
UDP test davá víc proto, že nezávisí na odezvě spoje. A UDP test zatěžuje o tolik míň koncové strany proto, že btest při UDP využívá fligny, že se nepočítají při odesílání a následně při příjmu UDP checksumy (kontrolují se jen IP záhlaví checksum). To UDP umožňuje a kdysi to Sun prosadil kvůli zvýšneí výkonosti pro NFS (spoléhá se na pošetření přes CRC na L2 vrstvě, pokud to L2 neumí, nemá se vypnutí UDP checksumu pouřžívat). U TCP to vypnput nelze a ten CPU v RB odejde na tom sečítání nulových čísel (ano, jsou tam šmejd CPU a chcecksum offloading do hardware síťovky stále nikde). Pokuzd se RB CPU fláká, tak kontrola, zda používáte po cestě contrack, pokud není nutný, tak vypnout (contrack pro TCP spojení je o fous náročnější než pro UDP), taktéž firewall, není-li nutný, tak vypnout. Pak forward paketu přes router po cestě je nezávislý na tom, zda je to TCP nebo UDP...

Pak už je to bohužel na tom, jak se daná konvové aplikace vyrovnají s profilem daníé trasy. Ovlivní to hlavně odezva linky časová, potom stabilita té odezvy (pokud hodně při zátěži lítá TCP ACK odezva, tak to na max nevytížíte) a nakonec chybovost. Bohužel řetězení half duplex linek za sebou je smrt pro TCP obecně a je jedno, jakou technologii používáte. Samozřejmě nv2 s oknem víc ms způsobuje, že jedno spojení to celé neucpe na max, pokud apliakce/OS neumí řídit TCP spojení na max.

Jediné řešení je snažit se minimalizovat odezvy linek a držet je pokud možno na konstantní hodnotě pod zátěží a s minimální chybovostí....

Ta myšlenka, zkusit to TCP spojení tunelovvat třeba v L2TP nemá smysl, pro ty routující routery uprostřed je to na stejno (není-li hodně debilní stavový firewall v cestě), doba průchodu bude stejná. Pokud má smysl, tak leda MPLS v režimu IP akcelerátor, které na RB433AH urychlí průchod paketu routerm o cca 100 us (proti holému IP routingu), ale pokud ta tím bude několik linek na bázi NV2 s několik ms oknem čekání na shluk dat, tak si na celkovém času moc nepomůžu...
Padla otázka, zda IPv6 je na tom stejně? Dokonce IPv6 by na tom mohlo být lépe než IPv4, protože po IPv6 routeru se chce ještě méně, než po IPv4 (zrušem chechsum záhlaví), ale opět se bavíme o zlomcích us v routovacím procesu proti milisekundám na NV2 vrstvě.


Jinak hodnoty zcela v normě. Mám tu třeba linku, kde je 17 GHz uplink, brána RB1100AHx2, nano bridge, RB493AH router, sextanxt-sextand bridge linka (nyní nstream), RB435G router baráku, za tím RB433UAH nebo RB800 koncový home router.
V UDP to dá up/down 48/48 Mbps (řezaný limit linky) mezi RB1100AHx2 a RB800 i RB433. V TCP to dá 22/12 pro RB433UAH nebo 22/22 pro RB800. Pokud za to připojím WinXP a pustím btest tak UDP cca 30/30 Mbps, a TCP 20/10 Mbps. Když nabootuji Win7, tak UDP 46/46 Mbps a TCP 25/15 Mbps. Pokud měřím proti speedtest.net, tak XPčka dají 22/15 Mbps a Win7 33/20 Mbps. Ano Win7 má trošku lepší IP stack.

[net.work]

takze jedine reseni je donutit mikrotik, aby opravil nstreme na mimo spojich, kde je latence +- 1ms...

[Majklik]

Jo, dá se říci, že by to mohlo mít nějvětší efekt. Pak je spousta věcí, za co by je šlo kopat, ale už to moc nenahoní.
Možná, kdyby do nv2 dali itneligenci detekující zuřivý tcp provoz a na základě toho protistraně dovolil vysílací slot třeba dříve nebo opakovaný v jendom okně (pokud to nv2 podporuje) pro oeslání toho TCP ACK. Ale NV2 je primárně myšlena na to PTMP a udržení tam rozumných parametrů pro všechny za cenu, že jeden z toho max nedostane.
Další by bylo na čase, ať tam začnou strkat ethernet čipy s podporou IP offloading a začnou je i podporovat a další... Fast path je hezké, ale jen na pů cesty.

[hapi]

tohle tady snad všichni víme nicméně popřepínání cele trasy na nstreme a nebo na nv2 nebo dokonce na holý Nko nemělo absolutně žádný efekt na propustnost v tcp.. bohužel. Chyba bude nejspíš ještě úplně jinde. Myslim že dojdeme k závěru že jediná možnost bude přechod na duplexní spoje ať už v profi pojítkách či nstreme dual. Je dost možný že ten problém s propustností tcpka přes wifi tu vždy byl nicméně až poslední dobou po tom chceme opravu obrovský rychlosti přes několik hopů.

[okoun]

jo ale když budeš přehazovat všechno na NSdual tak dostaneš 40Mb FDX a to nejsou zase superrychlosti, takže se tím nic nevyřeší, to by jednině musel NSdual ject v nku aby to dávalo 80Mb FDX

[net.work]

ale houby.. v single nstreme (treba na 40Mhz kanalu) umim z 1 TCP dostat klidne 60mbit (a to mi tu ted tece jeste 10/2 realneho provozu)....

[hapi]

down dám na 2x2 a upload na 1x1. Rate 130 na 65. Teoretická rychlost 80 na 40. A nebo down přepnout na 40MHz a cajk. Jemu spíš šlo o to že se zasere už takhle hodně a dual by zasral zase další kanál nicméně jenom jednim směrem a daly by se lépe koordinovat kanály na sajtu. Třeba jako všechny TXka na sajtu na stejnym 40MHz kanále což by bylo na druhou stranu brutální úspora pásma.

Nebo ono nejde použít 2x2 u nstreme dual?

[net.work]

down dám na 2x2 a upload na 1x1. Rate 130 na 65. Teoretická rychlost 80 na 40. A nebo down přepnout na 40MHz a cajk. Jemu spíš šlo o to že se zasere už takhle hodně a dual by zasral zase další kanál nicméně jenom jednim směrem a daly by se lépe koordinovat kanály na sajtu. Třeba jako všechny TXka na sajtu na stejnym 40MHz kanále což by bylo na druhou stranu brutální úspora pásma.

Nebo ono nejde použít 2x2 u nstreme dual?

No podle me ne - pac nebudes mit dostatecny kanalovy rozestup a bude se ti to rusit...

[hapi]

jakto? TXka na sajtu přece nevadí, to odpálí pryč a děj se co chceš. Nebo myslíš že ten přijímač na proti uslyší i ostatní směry na tom sajtu?

[Majklik]

Hapi, souhlas, je jedno, jaký half duplex použiješ, maximálně to má nějaký dopad. Průser je hlavně několik HD linek za sebou, kdy na každém hopu musí paket čekat na další okno pro přeskok dál. Výraznější zkrácení dostaneš až u plného duplexu.
Ale pokud teď ti to stojí na tom zřetězeném HD, tak pak poskočíš na FD a budeš stát na tom, že pro rychlé FD linky to ROS s těma současnejma krabičkama už neukrmí.
Ono by šlo udělat synchronní řízení těch zřetězených HD linek tak, aby paket na přestupním routeru nečekal, ale nevím, že by ROS něco takového podporoval (pak ale zase budou routery bombrdovat špičkové bursty, co se těm RB nemusí líbit). Pak by paket poskakoval "plynule" s minimálním čekáním na routeru po cestě (a fakticky současně obousměrně).

[hapi]

hmm nemyslim si že by to RBčka nezvládnuly. Jo jako někdo na páteřích dělá kraviny ve filtrech atd.. ale to je trochu kravina. Fakt si nemyslim že by to nedaly. Případně tu máme alixe kterej si to dá v pohodě do stropu fast ethernetu. No ale to jsou nemalé investice.

Nebo budu muset vypustit vzducholoď osazenou hromadou směrovek abych to napálil na přímo do každý vesnice

ne ale vážně, ubnt useři se nějak nehlásí, nemaji to jak otestovat?

[Majklik]

Jasně, cokoliv typu RB4xxAH ukočíruje takovéto rychlosti v pohodě (pokud někdo nepoprasí fw/q na každém hopu). A pokud při tlačneí přes ethernet porty se pokusím dodržet, aby uplink byl na samostatném portu a downlinky na switchcipu. Teď jsi v té fázi, že tě primárně brzdí ty zřetězené HDčka. A jak teď přemýšlím (už to moc nejde touhle dobou), tak zřetězení HD asymetrických linek bude mít na odezvu TCP ještě o něco horší dopad, než řetězení symetrických linek.

Add UBNT. Nemaj zrovna oni něco na řešení těch synchronizovaných přenosů - AirSync? Nebo tne jen funguje pro PTMP základnovky, ať jedou synchronně a neruší se vzájemně? Point-to-point nepodporují?

[hapi]

A jak teď přemýšlím (už to moc nejde touhle dobou), tak zřetězení HD asymetrických linek bude mít na odezvu TCP ještě o něco horší dopad, než řetězení symetrických linek.

co myslíš tou symetrickou linkou?

[Majklik]

Symetrická/asymetrická myslím z pohledu časového multiplexu. Když to přeženu, 1 ms vysílám a 1 ms přijímám je symtrie, proti variantě 1,5 ms vysílám a 0,5 ms přijímám jako asymetrická. V druhé vriantě dosáhnu většínho datového proudu ke klientovi, neboť beru, že hlavně konzumuje, ale bude horší časová odezva pro TCP ACK, jakmile bude víc takovýchto linek zřetězeno za sebou.

[hapi]

teď je otázka... tcp stack by to měl vyrovnat pokud ovšem se neupřednostní na wifině ACKčko který nastaví tcp stack na méně agresivní hodnotu ale potom už samotnej přenos nemá potřebný parametry na to aby dostál svému nastavení.

Možná melu z cesty ale kdy a podle čeho se stanový velikost tcp window size? podle RRT mezi SYN a SYN-ACK? Jak to funguje? až se přenese celí window size tak se stanový jiná velikost pro nový okno podle předchozí komunikace?

Asi zkusim loopnout přes klienta iperf a nastavit si ručně tcp window size jestli to vytahne aspoň 40Mbit FDX s nadopovanym window size.