Ubiquiti 24 GHz

[hapi]

to bylo v 5GHz navíc tam kde už bylo plno. To je docela rozdíl ne? Jak by se ti líbilo kdybych se ti přisral do pásma nad 5GHz a sundal ti páteřní spoj? Proto tu máme "kdo dřív příjde, ten dřív mele" takže sem přišel a roztahnul alcomu na max. Stejně tak jako přišel sysdatacom a nasadil si tam šmejd nad šmejdů SAF 24GHz kterej prostě zaruší cokoliv v tom pásmu. Ale oni tam byly první tak jsme přesedlaly na 17GHz. Kapišto?

[GRFS]

Hapi pojem "funguje" ma mnoho rozmeru. Ono to AFko zajiste "nejak" funguje tem, co pres nej jen brouzdaji na netu. A k tomu to presne je. Proti tomu nic. Co je podle me problem neni ani tak vlastni AFko, ale to co se z nej nekdo snazi delat. Jako paterni spoj ma AFko velmi limitovane pouziti a nelze jej absolutne srovnavat s cimkoliv jinym na trhu do pasma 24G. Proto je to taky tak levny. Tebou neustale omilana srovnani s MP600 jsou zcela mimo misu a ma smysl, abys to tu siril nejdrive v okamziku, kdy budes schopen rozlisovat alespon mezi agregovanou prenosovou kapacitou a FD.

Mimochodem zabirat velkou sirku pasma s vedomim, ze ji stejne nevyuzijes a delas to jen proto, abys nedovolil spektrum pouzit nekomu dalsimu, hovori minimalne o tve osobnosti a tou tady asi fakt nezabodujes. Staci si uvedomit treba to, ze na 24G jsi neuspel hlavne diky tomu, ze AFko zabira 200MHz pasma a pouziva obe polarizacni roviny pro TX i RX a prave proto neni schopno jednoduse koexistovat s jinymi spoji ve stejnem pasmu. Obavam se, ze i kdyby tam sysdatacom mel cokoliv jinyho, vcetne Alcomy, tak to bude tvymu AFku vadit. Proto jsi musel presedlat na 17G.

Tak si konecne sahni do svedomi, priznej si jak to je a prestan porad hledat viniky sve neschopnosti jinde nez v sobe. Koupil jsi levny AFko a dojel jsi na to. Divim se Alcomakum, ze po tom co jsi sem nakydal za blbosti, jeste meli vubec chut ti dodat na testy MP600.

[Fidoo]

Zdravím diskuzi.
Z pozice firmy která má za sebou instalaci stovek SAFů (17 i 24 GHz) nechápu hapiho tvrzení, že zaruší cokoliv. SAF je FDD spoj s normovaným vysílačem do masky dle ETSI normy. Díky tomu, že SAF tyto spoje vyrábí i do koordinovaných kmitočtů jsou parametry striktně dodržovány a mimo jiné se jedné o velice stabilní technologie. Datasheety zde porovnávat nebudu, ale SAF strká spoustu konkurence do kapsy. Pokud některý ze spojů SAF prokazatelně zarušil zařízení na jiném kanále, musí se jednat o vadu konkrétního kusu a je možné jej ve VanCo reklamovat, protože veškeré spoje CFIP Lumina mají 5 letou záruku. S touto závadou jsme se však nikdy nesetkali.

[hapi]

Hapi pojem "funguje" ma mnoho rozmeru. Ono to AFko zajiste "nejak" funguje tem, co pres nej jen brouzdaji na netu. A k tomu to presne je. Proti tomu nic. Co je podle me problem neni ani tak vlastni AFko, ale to co se z nej nekdo snazi delat. Jako paterni spoj ma AFko velmi limitovane pouziti a nelze jej absolutne srovnavat s cimkoliv jinym na trhu do pasma 24G. Proto je to taky tak levny. Tebou neustale omilana srovnani s MP600 jsou zcela mimo misu a ma smysl, abys to tu siril nejdrive v okamziku, kdy budes schopen rozlisovat alespon mezi agregovanou prenosovou kapacitou a FD.

Mimochodem zabirat velkou sirku pasma s vedomim, ze ji stejne nevyuzijes a delas to jen proto, abys nedovolil spektrum pouzit nekomu dalsimu, hovori minimalne o tve osobnosti a tou tady asi fakt nezabodujes. Staci si uvedomit treba to, ze na 24G jsi neuspel hlavne diky tomu, ze AFko zabira 200MHz pasma a pouziva obe polarizacni roviny pro TX i RX a prave proto neni schopno jednoduse koexistovat s jinymi spoji ve stejnem pasmu. Obavam se, ze i kdyby tam sysdatacom mel cokoliv jinyho, vcetne Alcomy, tak to bude tvymu AFku vadit. Proto jsi musel presedlat na 17G.

Tak si konecne sahni do svedomi, priznej si jak to je a prestan porad hledat viniky sve neschopnosti jinde nez v sobe. Koupil jsi levny AFko a dojel jsi na to. Divim se Alcomakum, ze po tom co jsi sem nakydal za blbosti, jeste meli vubec chut ti dodat na testy MP600.

já ti nevim, máme na tom 500 lidí, přijdu k zákazníkovy, vytočim tam na speedtestu 100Mbit a jdu domu. Jestli tomu říkáš že to nějak funguje tak mi řekni jak to má fungovat líp. Stejně tak dobře mi funguje MP600 takže to prostě srovnávat budu.

To že sem zabral plnejch 2x100MHz na MP600 je ochrana investic, tak jak se tady při uvedení PBM10 oháněla většina lidí. Nekoupil sem pojítko za skoro čtvrt milionu jenom proto abych za pár let až budu tu kapacitu potřebovat, zase neřešil nový pojítko.

bohužel, AFko jelo v pohodě dál, SAF kulhal. On teda kulhá i když tam AFko už neni ale za to si může ten kdo to tam montoval.

jo a AFko má agregovanou kapacitu? co si pod tim mám představit? já vim že to je FD pojítko, jestli seš jinýho názoru tak sem s tim.

A víš ty co? řekni mi jednu věc. Seš "zaměstanec" ISPíka nebo jeho vlastník/investor co do ní kupuje tyhle zařízení?

[lukas-svk]

Z ineho sudka. Hapi, alebo vlastnici AF24, aky fw teraz prevadzkujete? Skusali ste neiekdy test tlacit obomi smermi traffic? Ja som riesil nieco take na af24 spoji. 2 x 10/100 switche s 1GE uplinkami prepojene AF24 ( 1GE ). 2 servre na oboch stranach. Ak skusam testovat a tlacim traffic z jednej strany na druhu, vysaturujem port. Ak skusam toto iste ale obomi smermi, jeden smer ide relativne dobre (10MB/s) a druhy ide 2MB/s. Mas zapnuty flow control?

Pripadne ci to spravne chapem, kedze testujem "len" pomocou tcp prenosu, tak nedokazem vysaturovat oba smery preto lebo potvrdzovanie pri tcp protokole je zdrzovane prave tym druhym prenosom?

Porovnaval som fw 1.1.2 a 1.5rc2 a pri rovnakych podmienkach sa mi zda 1.1.2 lepsia.

Dik L.

Jo a stale nerozumiem preco tu mnohi stale vypisuju o blbostiach len o AF24 nie .. kecy o spektre, efektivite. Nemalo by to byt viac technicke vlakno o skusenostiach z prevadzky?

[hapi]

nějakou poslední betu tam mám. Flow control přirozeně vypnutý.
Jak může jeden směr ovlivnit druhej když je to full duplex? nemáš to přepnutý na half duplex? a jak to vůbec může ovlivnit když tam máš pouze 10MB/s? neni to tim testem?

update: teď jsem to zkusil i na vzdory vysokému zatížení a mezi bránou a RB951G to dalo 70Mbit tam i zpět na jedno spojení tedy direction nastaveno na both. Vim že to dá víc ale to rbčko je teď pod zátěží.

[lukas-svk]

noo lebo lebo pri tpcp spojeni by si mal jednotlive bloky dat o velkosti okna potvrdzovat a prave neviem ci to nerobi ten problem .. btw robis ten test tcp alebo udp? a mas tie oba porty na 1G alebo 100M ? Ja mam na oboch stranach testovacie stroje na 100vkovom porte a je to uz blizko maxima jednym smerom.

U mna to vyzera takto v pripade ze nejdu oba smery naraz ( FW 1.1.2 )

------------------------------------------------------------
Client connecting to 192.168.1.12, TCP port 5001
TCP window size: 85.6 KByte (default)
------------------------------------------------------------
[ 5] local 192.168.1.11 port 51680 connected with 192.168.1.12 port 5001
[ ID] Interval Transfer Bandwidth
[ 5] 0.0-60.0 sec 674 MBytes 94.2 Mbits/sec
[ 4] local 192.168.1.11 port 5001 connected with 192.168.1.12 port 54022
[ 4] 0.0-60.1 sec 674 MBytes 94.0 Mbits/sec

takto spolu

------------------------------------------------------------
Client connecting to 192.168.1.12, TCP port 5001
TCP window size: 85.6 KByte (default)
------------------------------------------------------------
[ 5] local 192.168.1.11 port 51693 connected with 192.168.1.12 port 5001
[ 4] local 192.168.1.11 port 5001 connected with 192.168.1.12 port 54023
[ ID] Interval Transfer Bandwidth
[ 5] 0.0-60.1 sec 504 MBytes 70.4 Mbits/sec
[ 4] 0.0-60.1 sec 608 MBytes 84.8 Mbits/sec

UDP 95Mbit simultanne

------------------------------------------------------------
Client connecting to 192.168.1.11, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 240 KByte (default)
------------------------------------------------------------
[ 5] local 192.168.1.12 port 42885 connected with 192.168.1.11 port 5001
[ ID] Interval Transfer Bandwidth
[ 5] 0.0-60.0 sec 684 MBytes 95.6 Mbits/sec
[ 5] Sent 487774 datagrams
[ 3] 0.0-60.0 sec 682 MBytes 95.3 Mbits/sec 0.143 ms 0/486449 (0%)
[ 3] 0.0-60.0 sec 1 datagrams received out-of-order
[ 5] Server Report:
[ 5] 0.0-60.0 sec 684 MBytes 95.6 Mbits/sec 0.135 ms 0/487773 (0%)
[ 5] 0.0-60.0 sec 1 datagrams received out-of-order

[hapi]

testuju to btestem v mikrotiku. Nemám tam linuxový mašiny. Porty jsou v gigu. Test je TCP.

Jestli limituješ jednu stranu ethernetu tak je to docela možné že ti jeden směr prostě zdechne. Nejde omezit maximální rychlost testu?

[lukas-svk]

obe strany maju 10/100 port agreguje sa to do 1GE cez ten spoj, preto si aj nemyslim ze napr flow control moze pomoct resp min nie smerom k radiu .
Pozeram aj ze novsi fw je horsi, pri 95M udp tam uz je nejaka mala stratovost ..



------------------------------------------------------------
Client connecting to 192.168.1.12, TCP port 5001
TCP window size: 85.6 KByte (default)
------------------------------------------------------------
[ 5] local 192.168.1.11 port 51801 connected with 192.168.1.12 port 5001
[ 4] local 192.168.1.11 port 5001 connected with 192.168.1.12 port 54025
[ ID] Interval Transfer Bandwidth
[ 5] 0.0-60.0 sec 450 MBytes 62.9 Mbits/sec
[ 4] 0.0-60.1 sec 534 MBytes 74.6 Mbits/sec

------------------------------------------------------------
Client connecting to 192.168.1.11, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 240 KByte (default)
------------------------------------------------------------
[ 5] local 192.168.1.12 port 43436 connected with 192.168.1.11 port 5001
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 3] 0.0-60.0 sec 682 MBytes 95.4 Mbits/sec 0.059 ms 19/486646 (0.0039%)
[ 3] 0.0-60.0 sec 1 datagrams received out-of-order
[ 5] 0.0-60.0 sec 684 MBytes 95.6 Mbits/sec
[ 5] Sent 487799 datagrams
[ 5] Server Report:
[ 5] 0.0-60.0 sec 684 MBytes 95.6 Mbits/sec 0.212 ms 1/487798 (0.00021%)
[ 5] 0.0-60.0 sec 1 datagrams received out-of-order

[hapi]

myslim že limituješ fast ethernet.

[Dalibor Toman]

obe strany maju 10/100 port agreguje sa to do 1GE cez ten spoj, preto si aj nemyslim ze napr flow control moze pomoct resp min nie smerom k radiu .
Pozeram aj ze novsi fw je horsi, pri 95M udp tam uz je nejaka mala stratovost ..

IMHO testujes ani ne tak schopnosti AFka ale to jak se switch vyrovna s prechodem 1Gbps port -> 100mbps port (a TCP prizpusobi max rychlosti linky). Pokud mas rozumnejsi switch, podivej se zda se neobjevuji nejake chyby na tech 100vkovych rozhranich (OutDiscards, Drops,...). I kdyz jedno TCP spojeni asi moc velke bursty nezpusobi (zalezi kam vyleze TCP window).
Dokud nebudes mit Gbps porty na mericich strojich tak to mereni nema moc smysl...

[neverhappy]

Tak jsem zkusil merit taky rychlost btestem a je to nejake divne. Mam nastaveno QPSK a v UDP namerim jednim, druhym a obouma smery 240Mb, coz odpovida. V TCP testu to jede jednim i druhym smerem 220-230Mb ale obouma smery to da 110Mb. Ping se drzi vetsinou na 0, obcas tam skoci 2ms. Je jedno, jestli tam je TCP conction 1,10 nebo 20. Pojitko hlasi ze je full duplex . Testovaci masiny jsem nevytizil vic jak na 60% na obou. Verze firmware v1.5-Beta2.17567

af24.JPG (96.83 KiB) Zobrazeno 2141 x

[Viktor Novotný]

to je ale velike prekvapeni

[neverhappy]

to je ale velike prekvapeni

Vedel jsem za za ty penize nekupuji mercedez. Jelikoz je to pro cca 70 klientu, a symetricky provoz nepotrebuji, tak jsem zatim spokojen. Proto tam mam QPSK, kdyz to pustim na plno tak z toho s prehledem dostanu 500Mb/100Mb coz 70-100 lidi nevyuzije hooooodne dlouho. Je pravda ze uvazuji nad Spoj Siklu EH1200TL - ft s alternetiva za 58 000,- Potrebuji spoj na 1,2km. Ten af24 bezi na 700m 6 mesicu zatim bez jedineho vypadku s prumernym ping 0.6 ms. Jelikoz mam klienty s 99 % na wifi, tak na tohle je to pojitko dostatecne.

[David2006]

Těžko radit co by na těch 1.2km bylo pro Tebe lepší řešení. Siklu dá papírově 300/100Mbs , bude mít menší příkon a menší antény pro montáž. Koukám Vanco srovnalo ceníkovou cenu na 58tis taky. Každopádně airFiber bude robustnější řešení - známému padlo tohle Siklu na 600m, tak tam dal airFiber. Další co vzít v potaz je že jednoho airFibra máš, pokud bys někdy vzal náhradní jednotku máš ty spoje z jednoho modelu. V případě i4wifi 5let záruky (třeba na to odpadnutí hliníku ). Pokud na to nespěcháš nechal bych se inspirovat v Říjnu s čím přijde Ubiquiti a jeho Revoluce (airBlast, nanobeam, AC produkty...).