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

[Majklik]

"na wifině ACKčko" máš na mysli změnu MSS? Tohle jen ovlivňuje, zda bude docházet k fragmentaci.
Fakticky, v TCP v SYN a SYNACK paketech se inzruje velikost MSS. To uvádí jak veliké TCP segmenty se můžou posílat. Obvykle se nastavuje na velikost dle MTU-velikost IP/TCP záhlaví, aby nedocházelo k IP fragmentaci.
Dále se v každém paketu inzeruje protistraně, jaká je velikost přijímacího okna (windows size). To je čistě věc přijímače, kolik má paměti, jak při otvírání nastavil bafry. Udává to aktuálně nepřekročitelný limit, kolik může vysílač odeslat bez potvrzení. Vysílač v reálu posíla toho kolikrát míň. Z křištálové koule si určuje congestion window. To je množtví dat, co si myslí, že je po cestě a které může odeslat a ještě se nic neztratí, než dojde jejich potvrzení.
A tady je asi 10 algoritmů, jak se to dělá. Přijímač potvrzuje každý (později každý druhý) přijatý segment (a zároveň tím hlásí i kolik ještě vezme do bafru ve window size). Vysílač po každém potvrzení zvětšuje množství naráz odeslaných dat v násobcích MSS (ale max do inzerovaného window okna přijímače) nebo dokud není na cestě nějaké množství nepotvrzených segmentů a pak čeká na potvrzení. Když potvrzneí přijde, pořdá zvětšuje posílaný blok (až do win size), než se něco ztratí (nepřijde potvrzení po dobu X, pa azačne opakovat nebo přijímač sám ohlásí detekci ztraceného segmentu aktivním poslání víc ACK). pak velikost bloků zkrátí na polovičku a jede znova v přidávání. A tak pořád dokola to pilovitě skáče tam a zpět (lehce zjednodušeno).
Takže hlavním limitem je to, jaké windows size přijímací strana maximálně dovolí (primárně dáno, co apliakce si otevřela jako velikost bafru, žádný vztah k rychlosti linky a jejímu zpoždění, ...) a pak jak rychle to bafrů vyčítá. Když to bude dělat pomalu, tak linku neucpe, protožr bude povoleno okno pro vysílání se plácat kolem nuly. Když okno bude moc malé (blbě zvolenýá velikost bafru), tak i když ho bude udržovat pořád prázdné, tak to neucpe při delším RTT linky - tabulku znáš - nepošliu víc než window size, pak čekám na potvrzení, než posílám dál.

Pro tebe, bohužel, vychází jediné - zkacuj RTT, zkracuj RTT, drž ho konstantně, drž ho konstantně, protože programátoři jsou matláci a nepářou se s tím (v nkterých případech ani nemůžou, viz ten Seznam)...
Takže pokud budu muset živit víc half duplex linek za sebou - mlať do Mikrotiku, že chci synchronizované PTP linky (třeba jako nadstavba do NV2).

[okoun]

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)....

ale to jóóó, to je ale teoretické všechno na stole, jen málo lokalit máš se dvěma kanálama o 40MHz, které nejsou obsazené!
V dnešní době se starat ještě o dvojnásobek kanálů na 5GHz je fakt moc, mě už stačí hlídat všechny ty kanály co mám teď a nedovedu si představit to znásobit dvěma

[hapi]

hmm, pokud tedy window size se určuje samo od sebe bez závislosti na latenci cesty a je závislý na nastavení obou stran (což je vlastně logický) tak to jsme dost v prdely. RTT se zkrátit už nedá. Jo nstreme ukazuje pěkný latence jenomže jenom pokud nikdo nic netahá. Pak snadno překračuje latenci NV2. No ale stejně, když popřepínám 3 spoje za sebou na cokoliv, změny jsou zanedbatelný. Já mám takovej pocit, že něco posraly protože před rokem co jsme vystavěly nový oblasti tak co si poamatuju speedtest běhal úžasně. Dneska je to na vyliž mi.

[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)....

ale to jóóó, to je ale teoretické všechno na stole, jen málo lokalit máš se dvěma kanálama o 40MHz, které nejsou obsazené!
V dnešní době se starat ještě o dvojnásobek kanálů na 5GHz je fakt moc, mě už stačí hlídat všechny ty kanály co mám teď a nedovedu si představit to znásobit dvěma

ale tady nejde o kanalovani - to byla jen ukazka toho, ze na single nstreme nemam absolutne problem vyuzit celou kapacitu spoje jednim TCP conectem...

[Majklik]

Psal single nstreame na 40 MHz, to předpokládám A v turbo? To jeo, to těch 60 Mbps může jendomu dát. ale trošku hůře se to podělí, když jich tma je víc. A pravda, kanálů není moc.

Celé to FD je problém o tom, že kyž vezmu těch 60 Mbps download, tak to je cca 6500 paketů/s v délce 1500 bajtů. A na to se musí současně zpět kontinuálně tlačit 3250 p/s s TCP ACK o pár bajtech (40 bajtů, jen prázdné IP-TCP záhlaví), jinak to nepojede (sekne se to na maximální velikosti okna nepotvrzených dat, co aktuálně odesílací strana má a jak má napočítán ssthresh, což může být i dost méně, než inzerované dostupné okno přijímací stranou). Jde jen o to, jak která HD technologie dokáže ty TCP ACK pakety s minimálním a konstantním zpožděním lifrovat zpět. Pokud HD přepíná relaitvně svižně a plynule se ACK vrací, tak to nastoupá k tomu, co jde fakt protlačit (není-li další provoz). Pokud technologie funguje tak, že čeká až se naskládá nějaké množství dat a teprve pak je odesílá, tak se to sekne, než se z těch 40 bajtů záhlaví poslkládá minimální balík k odeslání v celku nebo než až vyprší sestavovcí timeout, kdy dodje k odeslání i když není bafr plný. Čili, odesilatel pošle balík paketů odpovídající sstresh, ty dojdou příjemci rychle, vychrlí balík tcp-ack paketů zpět a pokud zpět je politika best fit (např u nstreme) a ten balík paketů neucpe aspoň jedno framing okno, tak se chvíli čeká... A TCP odesilatel čeká na ACK.. pak přestane HD bafr bavit čekání na další pakety (které nepřichází) a milostivě to pustí dál... A pokud je těch HD takto fungujících několik za sebou....
Takže pro nstreme a jeden TCP přenos jedním směrme by pak bylo nejlepší, aby směrem downloadu byla framing-policy best-fit a opačným se používala politika none (nečekat na zaplnění bafru). U NV2 je to v tom nv2-qos, kdy by zase byla situace, že nejlepší by blyo ve směru stahování použít frame-pirority (aby frejmy s TCP plnými daty měl nejvyšší prioritu, kteoru nastavím přes mangle) a opačným směrem nv2-qos na defualt, kdy přednostně odbavuje krátké pakety (nebo také frame-priority a naopak přes mangle by tcp ack měl dostat nejvašší prioritu). Bohužel to takhle úplně nastavit nejde a i když to tak dokopu, tak jendo TCP super, ale rozbiju celkovou propustnist...

A ještě jedna věc, jak funguje většina ekonomických teorii? Dost naprd... A jak funguje ten TCP algoritmus při řízení velikosti odesílacího okna? Je odvozen od jedné mikroekonomické teorie, takže funguje také celkem naprd... Přesněji, autoři asi nejrozšířenější verze jsou idealisti - předpokládá se, že zaseknutí provozu (nevrací se TCP ACK) v dnešních sítích způsobuje zahlcení linek, zkrátka se tám víc toho nevejde, ale nezpůsobujou to ztráty paketů. S touto myšlenkou to ten algoritmus řídí. Což platí pro optiku, switch eternet atd, bohužel ne pro wifi rádia. A proto, zvlášt v kombinaci s HD, to tak blbě funguje.

Add to window size - matematik by řekl, že dostatečně velká hodnota window size je podmínka nutná, ale nikoliv dostačující, abych z TCP vyrazil maximum. Pokud bude malé (což stále platí pro hodně apliakcí/OS), tak to zabiju na něm a dál s emůžu snažit jak chci. Další, víc ta ekonomická vsuvka o odstavec výše.

[hapi]

tak dnešní test:
xeon --- 10GHz --- RB450G --- alix ( 300Mbit TDMA 1ms ) alix --- RB411AH ( 300Mbit TDMA 1ms PTMP ) --- SXT = cca nad 30Mbit
xeon --- RB711G ( 300Mbit TDMA 1ms ) RB711G --- Omnitik ( 130Mbit TDMA 2ms PTMP ) --- SXT = cca pod 10Mbit

paradoxně je na tom první trasa latenčně hůř a přitom vykazuje 3x větší rychlost.

[hapi]

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)....

ale to jóóó, to je ale teoretické všechno na stole, jen málo lokalit máš se dvěma kanálama o 40MHz, které nejsou obsazené!
V dnešní době se starat ještě o dvojnásobek kanálů na 5GHz je fakt moc, mě už stačí hlídat všechny ty kanály co mám teď a nedovedu si představit to znásobit dvěma

ale tady nejde o kanalovani - to byla jen ukazka toho, ze na single nstreme nemam absolutne problem vyuzit celou kapacitu spoje jednim TCP conectem...

jednoho spoje ano, to taky dokážu ale tří spojů za sebou? to už je v řiťó.

[net.work]

není - dyt sem to tu psal - mam ty nstreme za sebou 3 (1x 40Mhz, 2x 20Mhz) a na konci je utlum na 1TCP max 10% celkove kapacity... Jak rikam - na single nstremech (politika best-fit, framer limit 3200) nemam absolutne zadny problem s 1TCP konektem... podotykam ze to nejsou Nkove karty a vse slape se 100% ccq bez zakolisani

[hapi]

jo, nejsou to Nkový karty, v tom to asi bude.

[Majklik]

tak dnešní test:
xeon --- 10GHz --- RB450G --- alix ( 300Mbit TDMA 1ms ) alix --- RB411AH ( 300Mbit TDMA 1ms PTMP ) --- SXT = cca 27Mbit
xeon --- RB711G ( 300Mbit TDMA 1ms ) RB711G --- Omnitik ( 130Mbit TDMA 2ms PTMP ) --- SXT = cca 10Mbit

paradoxně je na tom první trasa latenčně hůř a přitom vykazuje skoro 3x větší rychlost.

Hůř jako odezva na ping? To 10 GHz je rádio nebo PBM?
Hraje roli vzdálenost tras (to zvětšuje ochanou tichou mezeru, co se vkládá mezi vysílání jednotlivých bodů) a počet přihlášených klientů k nv2 AP. Potom ty 2 ms ti dávají, za jak dlouho se klient dostne k lizu. Pokud je tam víc klientů, kteří nepřenáší data, tak jim AP stejně nascheduluje časové okno, minimálně pro ohlášení velikostí front. Pokud to testované SXT jen vrací zpět TCP ACK, tak asi nemá zacpanou výstupní frontu tolik, že AP mu nedá o moc víc času, než druhým.
A další bod, co vůbec neovlivníš, je vzájemná synchronicita těch dvou TDMA mezi sebou, ta se v čase mění a po kažém restartu bude jiná. Take u druhé linky ti teoreticky vracející se ACK nejdříve v průměru muže čekat 1 ms, než ho předá na AP, potom znovu by v průměru 0,5 ms čeka, než poskočí tou bod-bod linkou. U prvního případu ti v průměru ack bude čekat prvně 0,5 ms na PTMP vrácení a pak 0,5 ms na okno k alixu.
Kde máš AP stranu toho TDMA toho bod-bod spoje? Automaticky tím znevýhodňuješ tu druhou stranu. NV2 AP dělá to, že ti přiděluje časové okno klientu pro vysílání, ale protože je dělán pro multipoint, tak automaticky nechává i časové okno pro neznámé, aby měli čas pro registraci. Takže i kdyby jsi chtěl přenášet oběma směry stejně a AP podělí vysílání své s příjmem na 1:1, tak ten jeden klient v PtP nedostane to okno celé, ale bu de v něm mezera pro případné nové příchozí (to by v nv2 mohli vylepšit, aby pro PtP konfiguraci nezdržoval se mezerou pro dalšího).

[hapi]

tohle já všechno vim a i otočení smyslu ap-klient už se konalo bez znatelný změny

10GHz je 1S10. Jo jako odezva na ping. Vzdálenost tras je shodou okolností stejná. PTP na 8km a PTMP do cca 700m. Jedinej rozdíl je v použitim HW. Nastavení, verze, všechno stejný. Poček klientů je u toho pomalejšího víc a hlavně mix Ačkařů s Nkařema nicméně právě tohle by měla NV2 vyřešit časovym přídělem takže by se měly ovlivňovat minimálně.

Chápu jak funguje TDMA v podání NV2 nicméně se mi zdálo "TDMA" v podání nstreme daleko lepší. Ano, nstreme měl "TDMA" na APčku na straně TX. Nejednalo se sice o časový rozdělení nicméně cyklicky obsluhoval klienty čimž jim zaručil download. U uploadu to bohužel neměl implementovaný takže torrenťák ho sundal. Ale co bylo hlavní je to že obsloužit klienty uměl za méně než je minimální čas u NV2 a proto taky nižší latence. Takže když už neměl data tak přepnul na příjem. U NV2 se stupidně čeká nebo spíš vypočítává pro další okno velikost jednotlivých rámců což už je 2x větší reakční doba.

Chápu TDMA u stávajících mobilních operátorů kde ale dostane hovor pevnej slot a hovor má vždy stejnej datovej tok a nedělí se o celkovou propustnost BTSky atd.. ale na wifi? tam nějak nechápu smysl.

[net.work]

Nv2 je paradni na APckach - nemuzu si to vynachvalit... jen se to proste nesmi cpat na P2P spoje... tady bohuzel chybi (jak sem psal vyse) funkcni nStreme na Nkovych (tedy spise dualnich) kartach... Nebylo by od veci otevrit tuhle otazku na MT foru - proc ten nStreme nefunguje...

[Majklik]

tohle já všechno vim a i otočení smyslu ap-klient už se konalo bez znatelný změny

Jo, pokud oba směry přenáší stejně, tak se podělí příjem/vysílání cca 1:1 a k tomu je tam okno pro nového. Velikost toho okna ovlivňuje nv2-cell-radius. Čím větší skok, tím větší díra pro slepé, která je u PtP zbytečné plýtvání časem (a tím pádem kapacitou). Mělo by tama být škrkátko, že je to PtP a zdar s oknem pro třetího. Pokud je přenos asymetrický, tka to okno jen zhoršuje odezvu.

10GHz je 1S10. Jo jako odezva na ping. Vzdálenost tras je shodou okolností stejná. PTP na 8km a PTMP do cca 700m. Jedinej rozdíl je v použitim HW. Nastavení, verze, všechno stejný. Poček klientů je u toho pomalejšího víc a hlavně mix Ačkařů s Nkařema nicméně právě tohle by měla NV2 vyřešit časovym přídělem takže by se měly ovlivňovat minimálně.

Ten HW by to měl být u těchto rachlostí zcela bez vlivu.

Neměly by se vzájemně vyrušit, každý má jen garantováno, že se na chvilku dostane k lizu po nějaké době. Garantuješ jen, že odezva nebude horší než X milisekund. Nic víc, zbytek je best effort...
Čím víc klientů, tím míň na každého garantovaně zbude i když ostatní nevysílají.

Chápu jak funguje TDMA v podání NV2 nicméně se mi zdálo "TDMA" v podání nstreme daleko lepší. Ano, nstreme měl "TDMA" na APčku na straně TX. Nejednalo se sice o časový rozdělení nicméně cyklicky obsluhoval klienty čimž jim zaručil download. U uploadu to bohužel neměl implementovaný takže torrenťák ho sundal. Ale co bylo hlavní je to že obsloužit klienty uměl za méně než je minimální čas u NV2 a proto taky nižší latence. Takže když už neměl data tak přepnul na příjem. U NV2 se stupidně čeká nebo spíš vypočítává pro další okno velikost jednotlivých rámců což už je 2x větší reakční doba.

Nstream ti zaručil, že se rádia vzájemně nepřeřvávají, ale čeká jak jsou jednotlivě vyzvány, což byl dost přínos (cdma off, pooling on). Zaručuje to efektivnější využití pásma, ale ne spravedlivější podělení mezi různé klienty. Jak klient měl co pořád posílat, tak tlačil po té, co byl vyzván, AP ho neutrhlo. Tohle řeší ten TDMA multiplex časovými kvanty.

U těch PTP linek nstream reaguje lépe proto, že reaguje u toho jednoho streamu rychleji na situaci. Ovysílám balík dat, víc nemám, přepínám na příjem, akorát tak nějak dojdou tcp ack, tak je poberu pošlu dál, klient nic nemá, hle přichází další TCP data, tak je vysílám. Reaguje svižně na ten tok. V podstatě ten časový multiplex je dynamický, je to spíše PWM modulace dat.
Čisté TDMA si jede ve svých slotech a zdar... Pomohlo by, kdyby ty časové sloty mezi PTP spoji byly synchronizovány, pak by odpadlo to čekání na přeskok v rádiích a uděláš z toho prakticky synchronní spoje, to by pomohlo opravdu znatelně (ideálně v kombinaci s fast forward).

Chápu TDMA u stávajících mobilních operátorů kde ale dostane hovor pevnej slot a hovor má vždy stejnej datovej tok a nedělí se o celkovou propustnost BTSky atd.. ale na wifi? tam nějak nechápu smysl.

Stejný smysl to má i u tebe, ale pro to, že chci nějakou služnbu s minimálníma garamntovanýma parametry pro koncáka. TDMA ti neumožní zázraky, ale zaručuje nějaký minimální standard. Navíc i operátoři to TDMA mají na té last míli a ne hopy před tím. Toho se je třeba také držet...

Takže mlátit za ten nstream, ať to opraví, který tu iluzi duplexní linky vyráběl efektivněji. To HD se projevuje i zde v dopadu na přenosovku TCP, ale mnohem méně, než na čistém TDMA na jedne stream.

Druhá cesta je boj za synchronní NV2 PtP zřetězené spoje. Ale i jen synchronní NV2 pro APčka. Ale pochybuji, když i sync nmezo PtMP APčky je v nedohlednu...

[hapi]

podle mikrotiku velikost cell radiusu ovlivnuje pouze to jestli se klient po testu vzdálenosti do něj vejde nebo ne. Aspoň tak to někdo z nich na foru tvrdil. Prý to na nic jiného vliv nemá ale kdo ví.

Jasně, proto říkám u nstreme že upload nebyl ošetřenej. Download z pohledu klienta se přetížit nedal.

[hapi]

když už jsme to tu takhle pěkne rozvířily, na jinou stranu sítě, říkejme tomu 3 směr, to jede dobře a přitom tam jsou taky dva duální spoje na RB711kách + konečnej duál na ptmp. TCP test tam jede 30Mbit.