Cambium ePMP 1000

[hapi]

víš jakou měly latencí první canopky? 25ms!! každý TDMA musí mít timesloty.

To že si někdo dá dva sektory zády na jednu trubku a použije gps sync pro sync rx a tx neznamená že to bude fungovat. Všichni jasně víme že i 8km vzdálenej sektor pěkně naruší apčko.

jestlize vsechny APcka maji povoleno vysilat jen v urcity cas - tak se nemohou rusit navzajem (krome cerne magie intermodulacniho zkresleni, kdy jedno AP kazi vysilany signal druhemu). Proste RX kanal v tu chvili na AP antene nikoho nezajima. A je jedno jestli ty APcka jsou na jedne frekvenci. Kanalove od sebe musi oddelit sousedni sektory kvuli klientum, kteri jsou videt z vice sektoru.

ale běž, vypni si jeden sektor na sajtu a uplně v pohodě si přepoj klienty na druhej zády k němu. Jakto že mě RX nezajímá? vždyť uslyšim TX dvou klientů (jeden můj, druhej jinýho sektoru) na jednom RX sektoru. To ovlivní příjem na sektorech stejně tak dobře jako bez syncu.

[ludvik]

A o tom se už možná několik let bavíme ... nemají to dodělané.
Synchro musí synchronizovat nejenom vysílání AP, ale i vysílání klientů. Tedy distribuovat timesloty v rámci jedné "GPS domény". Pak to fungovat bude. Sice logicky klesá upload, ale to lze většinou oželet. Download klientů bude naplno.
Ale asi mají problém s tímto řešením. Myslím, že by potřebovali asi i GPS u klientů, kvůli přesnosti časování.

ale běž, vypni si jeden sektor na sajtu a uplně v pohodě si přepoj klienty na druhej zády k němu. Jakto že mě RX nezajímá? vždyť uslyšim TX dvou klientů (jeden můj, druhej jinýho sektoru) na jednom RX sektoru. To ovlivní příjem na sektorech stejně tak dobře jako bez syncu.

[hapi]

to asi neee. Přece apčko určuje kdy má vysílat klient ne? Já se bavim přece o něčem úplně jinym.

[ludvik]

A o čem tedy?

to asi neee. Přece apčko určuje kdy má vysílat klient ne? Já se bavim přece o něčem úplně jinym.

Bavíme se o tomto ... UBNT GPS Sync ovlivňuje jen vysílání. Všechny AP vysílají jen v jeden okamžik. Takže teoreticky mohou být na stejném kanále. Ale timesloty pro upload má každé takové AP svoje vlastní. Takže klidně může nastat to, co píšeš ... klient z druhé strany bude slyšet na AP na opačné straně stožáru. Proto samo UBNT doporučuje mít použito kanálů víc - buď dva když jsou 4 sektory, nebo 3 pro tři sektory. Aby ap "neslyšelo" klienty jiné, než svoje.

Jenže to nemá. Takže jediné, co to jakžtakž řeší je to, že lépe pracují na kanálech hned vedle sebe. Jenže to zabíjí implementací, kdy přenosovka takového řešení padá skoro na polovinu ...

Pokud bude zajištěno, že i klient může vysílat jen jeden v jeden okamžik, ať už mám v GPS syncu zapojeno APček kolik chci, může to fungovat vše na stejném kanále.

Řekl bych, že řešení jiných výrobců tuto moji domněnku potvrzují.

[hapi]

jde mi o to že i když budou pouze klienti vysílat tak i jeden klient bude prát do ostatních sektorů svůj signál s rozdílem nějakých 20dB takže z toho bude velký smradlavý a hnědý.

[ludvik]

Čti co píšu ... jeden klient v jeden okamžik. Distribuce timeslotů v rámci všech AP zapojených v syncu. Jedno AP ví, že zrovna přijímá druhé - tedy nepovolí to samé svým klientům. Tedy se nemá co rušit.

jde mi o to že i když budou pouze klienti vysílat tak i jeden klient bude prát do ostatních sektorů svůj signál s rozdílem nějakých 20dB takže z toho bude velký smradlavý a hnědý.

[hapi]

pak nechápu proč bych to dělal to nemá vůbec žádnej význam kromě toho že si poseru upload
to si raději navolim jiný kanály nebo osadim všesměru

[ludvik]

Kanálů nemusíš mít na rozdávání ... a tím pádem zlepšíš download. Pro něj máš furt X apček. Ono při mizivém procentu uploadu oproti downloadu dle statistik ... co s ním taky, není potřeba. Ty občasné peaky od občasných userů to zvládne.

Nic lepšího na jedné frekvenci nevymyslíš. Řekni alcomě, ať tu svoji AL5F nebo jak se jmenuje předělají na PtMP

[Dalibor Toman]

víš jakou měly latencí první canopky? 25ms!! každý TDMA musí mít timesloty.

To že si někdo dá dva sektory zády na jednu trubku a použije gps sync pro sync rx a tx neznamená že to bude fungovat. Všichni jasně víme že i 8km vzdálenej sektor pěkně naruší apčko.

jestlize vsechny APcka maji povoleno vysilat jen v urcity cas - tak se nemohou rusit navzajem (krome cerne magie intermodulacniho zkresleni, kdy jedno AP kazi vysilany signal druhemu). Proste RX kanal v tu chvili na AP antene nikoho nezajima. A je jedno jestli ty APcka jsou na jedne frekvenci. Kanalove od sebe musi oddelit sousedni sektory kvuli klientum, kteri jsou videt z vice sektoru.

ale běž, vypni si jeden sektor na sajtu a uplně v pohodě si přepoj klienty na druhej zády k němu. Jakto že mě RX nezajímá? vždyť uslyšim TX dvou klientů (jeden můj, druhej jinýho sektoru) na jednom RX sektoru. To ovlivní příjem na sektorech stejně tak dobře jako bez syncu.

mluvil jsi o ruseni mezi APcky (viz ten odkaz na 8km vzdaleny sektor) a ted pises o klientech. Dobre anteny na AP, neprehuleni klienti (nejlepe funkcni ATPC) udelaji sve. A samozrejme nejlepsi je mit ty AP anteny ne na trubce ale na poradnym komine. A tech kominu pak muzes mit po meste vic a pokud vysilaji ve stejny cas tak se nerusi. A pokud klienti nestrileji na jedno AP skrz druhe tak nerusi taky.

[hapi]

jasně, takový podmínky jsou všude a všude začnu stavět železobetonový komíny aby technologie měly klid vrať se do reality. Apčka jsou běžně na panelácích a pokud možno na příhraně kde se prostě viději.

Nemluv tady o teorii a vrať se do reality. V realitě budeš třeba trpět odrazem od budov atd.. nemůžeš srovnávat vymazlený motorola chipsety v canopkách proti atheros chipům s přidanou gps. Stačí se kouknout na jejich citlivosti oproti atherosu a už víš že to neni žádná hračka a to je pouze jedna z výhod kterou motorola má oproti atherosu.

[Rasmo]

U Motoroly/Cambium SYNC nema zadny vliv na latenci/zpozdeni. Proc by synchronizace mela prodluzovat odezvu?

A těch 17ms je vycucanejch na vašich stránkách z prstu?
LATENCE (nominální, zpáteční) 17 ms

17ms latence je realita. Chapu, ze se to nekomu, kdo pouziva WiFi muze zdat jako sci-fi, ale je to tak

[David2006]

U Motoroly/Cambium SYNC nema zadny vliv na latenci/zpozdeni. Proc by synchronizace mela prodluzovat odezvu?

A těch 17ms je vycucanejch na vašich stránkách z prstu?
LATENCE (nominální, zpáteční) 17 ms

17ms latence je realita. Chapu, ze se to nekomu, kdo pouziva WiFi muze zdat jako sci-fi, ale je to tak

Také proto si myslím že je to spíše pro podnikové řešení možná vhodné na skomírající VOIP služby. Ale pro domácnosti je mnohdy lepší kvůli hráčům mít na nepřetíženém sektoru menší latenci která je pro AirMax protokol typická. Už vidím ty telefonáty že mají najednou o 10-15ms horší ping než byli za poslední 2 roky zvyklí (pokud odhlédnu od toho že stávající stejně nebudu měnit, leda na nové lokace). Berte to jen jako postřech a je dobré mít na trhu alternativu i když se mi nehodí do koncepce .

[Rasmo]

víš jakou měly latencí první canopky? 25ms!! každý TDMA musí mít timesloty.

To že si někdo dá dva sektory zády na jednu trubku a použije gps sync pro sync rx a tx neznamená že to bude fungovat. Všichni jasně víme že i 8km vzdálenej sektor pěkně naruší apčko. Canopy mělo kdysi napsaný někde pravidla o umístění anten. Bylo tam doslova napsáno jak se mají sektory na sajtu v jednom kanále montovat. Např: jak blízkou sebe mohou být (bylo tam minimálně 20m od sebe) pak jak pokrejvat okolí, kde má bejt umístěný apčko (jako že na vysoký budově a koukat dolu na klienty a to ještě tak aby klient jednoho sektoru neviděl antenu druhýho sektoru atd..)

všichni snad víme jakej signál má klient kterej svítí zády do tý nejsuprovější sektory na trhu. Odpověd je jednoduchá, stále furt dost silnej na to aby ho ovlivnil gps negps.

20m neni a nebylo u Canopy nutne. Site muze vypaat napr. takto a vse funguje jak ma.

[Rasmo]

U Motoroly/Cambium SYNC nema zadny vliv na latenci/zpozdeni. Proc by synchronizace mela prodluzovat odezvu?

zalezi, co porovnavas. Pokud Sync s dalsim TDMA pak je to teoreticky sul nul a rozdily budou jen diky velikosti timeslotu. Pokud porovnavas s beznou wifi tak tam samozrejme Sync prohraje - protoze Sync se bez timeslotu udelat neda. A predpokladam, ze se jedna u Cambia jedna o klasicky TDMA (tj, ze je rizeny provoz klientu = neprekrikuji se jak je napadne)

Presne tak. SYNC je u Canopy delana velmi jednoduchym a elegantnim zpuzoben. Na latenci ma nulovy vliv.
Jinak je to samozrejmne TDD/TDMA

[Rasmo]

A o čem tedy?

to asi neee. Přece apčko určuje kdy má vysílat klient ne? Já se bavim přece o něčem úplně jinym.

Bavíme se o tomto ... UBNT GPS Sync ovlivňuje jen vysílání. Všechny AP vysílají jen v jeden okamžik. Takže teoreticky mohou být na stejném kanále. Ale timesloty pro upload má každé takové AP svoje vlastní. Takže klidně může nastat to, co píšeš ... klient z druhé strany bude slyšet na AP na opačné straně stožáru. Proto samo UBNT doporučuje mít použito kanálů víc - buď dva když jsou 4 sektory, nebo 3 pro tři sektory. Aby ap "neslyšelo" klienty jiné, než svoje.

Jenže to nemá. Takže jediné, co to jakžtakž řeší je to, že lépe pracují na kanálech hned vedle sebe. Jenže to zabíjí implementací, kdy přenosovka takového řešení padá skoro na polovinu ...

Pokud bude zajištěno, že i klient může vysílat jen jeden v jeden okamžik, ať už mám v GPS syncu zapojeno APček kolik chci, může to fungovat vše na stejném kanále.

Řekl bych, že řešení jiných výrobců tuto moji domněnku potvrzují.

SYNC u UBNT nemuze fungovat uz z principu. Jedna to neni TDD a potom nelze synchronizovat neco, co ma promennou delku ramcu.