čau lidi. Tak jsem hledal co MK a polling, a jak to funguje.
normální stav vypadá takhle:
Client AP
DATA ->
<- ACK
DATA ->
<- ACK
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:
Client AP
RTS ->
<- CTS
DATA ->
<- ACK
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:
Client AP
<- POLL
DATA ->
<- POLL
DATA ->
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.
