classic.ISPforum.cz

Mate nekdo zkusenosti s OSBRIDGE?
Libi se mi ze ma implementovanou technoogii wireless pooling protokolu.
Zjednodusene reseno APcko shromazduje informace ktera ze stanic chce co prenest a pak prideluje casy jednotlivym stanicin k prenosu. Elimunije to kolize a problemy skrytych uzlu.

Neco podobneho mi stel chybi u MKtiku. Netusite kdy neco podobneho bude implementovano do MKtiku? Ten nema ani hloupe RTS/CTS.

"High Performance Polling Protocol umožňující připojení až 5x více klienstkých stanic k přístupovému bodu než v rámci standardního protokolu 802.11a "

Kaja

jakýsi polling má mikrotik taky...problém je v tom, že abys ho mohl použít musíš mít klienty taky na mikrotiku...na AP zapnout nstreme a v té samé záložce enablovat polling, u klienta pak taky zapnout nstreme a povolit v té samé záložce polling

RAket píše:jakýsi polling má mikrotik taky...problém je v tom, že abys ho mohl použít musíš mít klienty taky na mikrotiku...na AP zapnout nstreme a v té samé záložce enablovat polling, u klienta pak taky zapnout nstreme a povolit v té samé záložce polling

Zdravím,

chci se také zeptat, zda již někdo s produktama od firmy OSBRIDGE nemáte zkušenosti.
U nás to nabízí jedině a pouze wifiHW.cz, sortiment mají zde http://www.wifihw.cz/p288-b-5gi-b-5-6gh ... or-bridge/

Zajímalo by mě to spíš kvůli tomu NLOSu, co vím, tak to používají WiMAXy a funguje to v praxi slušně. Procík by měl těch 70MBit HD zvládat.

Cago,

tak prinasim prvni zkusenosti s OSbridge z praxe.
Mam to cca jeden v provozu na spoji delky 3km v huste zarusene mestske aglomeraci.
Spoj dava na TCP vrstve v default nastaveni Bandwidth testu cca 45Mbit jednosmerne a pri full duplexu cca 25/18Mbit.

Vic jsem od toho necekal, takze spokojenost, ale cena neni moc prizniva, ale nekdo to otestovat musel

no jo, ale co ty "timesloty" klientům o což jde předevšim...? Neni náhodou polling jenom to, že posílá velkej paket a každej klient si z toho jednoho velkýho vybere ty malí co patřeji jemu čimž se ušetří čas?

čau lidi. Tak jsem hledal co MK a polling, a jak to funguje.

normální stav vypadá takhle:


v normálnim stavu se můžou klienti slyšet na vzájem, což je dobrý ale je tu velká pravděpodobnost skrytých uzlů takže když začne v jeden okamžik uploadovat několik klientů najednou, dojde ke kolizi a tedy k opakování přenosu. Taky může jeden uploadující klient zahltit celí APčko.

RTS/CTS stav:


Problém skrytého uzlu trochu řeší tenhle případ. Klienti se ptaji jestli můžou vysílat (RTS). AP říká aby byly všichni sticha že tenhle klient bude vysílat (CTS). To zaručí aby nevznikaly kolize při uploadu na APčko protože všichni ostatní vědí, že maji počkat s uploadem. Neni to účinnej způsob protože každej klient musí žádat o upload a to může udělat i při tom když AP vysílá. Neni to perfektní řešení, protože AP nemusí slyšet RTS požadavky signálově slabších klientů a problémy se můžou ještě zhoršit.

a konečně polling:


Je to ideální. AP určuje kdo a kdy může uploadovat. Každý čeká až na něj cyklicky přijde řada takže se nevyskytujou kolize. Nevyskytujou se ani problémy se skrytými uzly či rozdíl mezi kvalitou signálu protože klienti nikdy nežádaji o upload. AP každýmu z nich cyklicky dá vědět že může uploadovat. U pollingu může být latence mírně vyšší, ale jitter menší protože klient má vždy šanci poslat během svého času data (timeslot). U systému založeného na odezvě by normální systém mohl vypadat jako "12, 34, 20, 150, 30, 80, 200" ale polling systém by mohl vypadat takhle "60, 61, 60, 60, 61, 60" což je velmi dobrý například pro VoIP.

Ukazuje to upload klienta. Stahování v podstatě pracuje stejně ve všech třech případech.




Už chápete proč mikrotik nemá RTS/CTS a proč při zapnutí nstreme se už neukazuje ack. time a proč trango, canopy a všechny tyhle drahý hračky maji minimální latence skoro 10x větší i když téměř konstantní?

Teoreticky se dá upload klientů poladit pomocí framer policy a framer limit kdy se definuje kolik toho může klient uploadovat v jeho timeslotu.

A ještě by mě zajímalo proč se tohle musim dozvědět na Ubiquiti Networks Forum a ne v manuálu MKčka.

Praktickej test mi ukázal, že největší žrout neni spojování paketů do jednoho většího ale právě polling.

jenomze kdyz vypnes polling tak ti klesne prenosova kapacita

vim no, asi to framer policy k něčemu potřebuje. Ale když jsem to testoval na cca 100m spoji tak vypnutej polling nic nezpomaloval a rychlost byla ok ale na 1km spoji šla rychlost dolu tak nevim kde je problém protože jinak nevim na co by tam byla možnost vypnout polling. Jo a co funkčnost AP MK proti nějakýmu Ubiquiti kterej má malou ramku, procák nic moc, ten musí dost trpět ne? Jestli jde zapnout polling jenom když běží nstreme tak Ubiquiti ho musí umět taky.