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