Ubiquiti 24 GHz

hapi

Ty hele, to pole tam je nejspíš pro modulovani dat do signálu ne?

Nebuďte paničky a pošlete tam UDP když stroje nestihaji.

jap

tak tu mame dalsi test s novym firmwarem - Version.1-beta1.14818

jeden smer:

root@suchdol:~# iperf -c 192.168.1.40 -i 30 -t 86400

------------------------------------------------------------

Client connecting to 192.168.1.40, TCP port 5001

TCP window size: 16.0 KByte (default)

------------------------------------------------------------

local 192.168.1.30 port 33858 connected with 192.168.1.40 port 5001

Interval Transfer Bandwidth

0.0-30.0 sec 2.23 GBytes 639 Mbits/sec

30.0-60.0 sec 2.23 GBytes 639 Mbits/sec

60.0-90.0 sec 2.23 GBytes 638 Mbits/sec

a 2 smery proti sobe (separatne spustene, pri -d mi to pada)

root@suchdol:~# iperf -c 192.168.1.40 -i 30 -t 86400

------------------------------------------------------------

Client connecting to 192.168.1.40, TCP port 5001

TCP window size: 16.0 KByte (default)

------------------------------------------------------------

local 192.168.1.30 port 33629 connected with 192.168.1.40 port 5001

Interval Transfer Bandwidth

0.0-30.0 sec 1.48 GBytes 423 Mbits/sec

30.0-60.0 sec 1.36 GBytes 389 Mbits/sec

60.0-90.0 sec 1.90 GBytes 544 Mbits/sec

90.0-120.0 sec 1.97 GBytes 563 Mbits/sec

120.0-150.0 sec 1.43 GBytes 410 Mbits/sec

150.0-180.0 sec 1.08 GBytes 308 Mbits/sec

180.0-210.0 sec 1.82 GBytes 521 Mbits/sec

210.0-240.0 sec 2.11 GBytes 604 Mbits/sec

240.0-270.0 sec 1.44 GBytes 413 Mbits/sec

270.0-300.0 sec 1.37 GBytes 392 Mbits/sec

300.0-330.0 sec 1.27 GBytes 363 Mbits/sec

330.0-360.0 sec 1.96 GBytes 561 Mbits/sec

0.0-362.4 sec 19.3 GBytes 459 Mbits/sec

a z druhe strany

root@pe3ny:~# iperf -c 192.168.1.30 -i 30 -t 86400

------------------------------------------------------------

Client connecting to 192.168.1.30, TCP port 5001

TCP window size: 16.0 KByte (default)

------------------------------------------------------------

local 192.168.1.40 port 37385 connected with 192.168.1.30 port 5001

Interval Transfer Bandwidth

0.0-30.0 sec 1.72 GBytes 492 Mbits/sec

30.0-60.0 sec 1.76 GBytes 503 Mbits/sec

60.0-90.0 sec 1.26 GBytes 360 Mbits/sec

90.0-120.0 sec 1.18 GBytes 337 Mbits/sec

120.0-150.0 sec 1.60 GBytes 459 Mbits/sec

150.0-180.0 sec 2.12 GBytes 607 Mbits/sec

180.0-210.0 sec 1.42 GBytes 407 Mbits/sec

210.0-240.0 sec 971 MBytes 272 Mbits/sec

240.0-270.0 sec 1.63 GBytes 465 Mbits/sec

270.0-300.0 sec 1.79 GBytes 512 Mbits/sec

300.0-330.0 sec 1.86 GBytes 532 Mbits/sec

330.0-360.0 sec 1.22 GBytes 349 Mbits/sec

a jeste ping v tehle zatezi - do 3ms

root@suchdol:~# ping 192.168.1.40

PING 192.168.1.40 (192.168.1.40) 56(84) bytes of data.

64 bytes from 192.168.1.40: icmp_req=1 ttl=64 time=1.47 ms

64 bytes from 192.168.1.40: icmp_req=2 ttl=64 time=2.08 ms

64 bytes from 192.168.1.40: icmp_req=3 ttl=64 time=2.67 ms

64 bytes from 192.168.1.40: icmp_req=4 ttl=64 time=0.916 ms

64 bytes from 192.168.1.40: icmp_req=5 ttl=64 time=1.63 ms

64 bytes from 192.168.1.40: icmp_req=6 ttl=64 time=1.64 ms

64 bytes from 192.168.1.40: icmp_req=7 ttl=64 time=2.73 ms

64 bytes from 192.168.1.40: icmp_req=8 ttl=64 time=2.15 ms

64 bytes from 192.168.1.40: icmp_req=9 ttl=64 time=2.27 ms

64 bytes from 192.168.1.40: icmp_req=10 ttl=64 time=2.74 ms

64 bytes from 192.168.1.40: icmp_req=11 ttl=64 time=1.79 ms

64 bytes from 192.168.1.40: icmp_req=12 ttl=64 time=2.62 ms

64 bytes from 192.168.1.40: icmp_req=13 ttl=64 time=1.79 ms

64 bytes from 192.168.1.40: icmp_req=14 ttl=64 time=2.48 ms

64 bytes from 192.168.1.40: icmp_req=15 ttl=64 time=1.94 ms

64 bytes from 192.168.1.40: icmp_req=16 ttl=64 time=1.21 ms

64 bytes from 192.168.1.40: icmp_req=17 ttl=64 time=2.42 ms

64 bytes from 192.168.1.40: icmp_req=18 ttl=64 time=2.65 ms

--- 192.168.1.40 ping statistics ---

18 packets transmitted, 18 received, 0% packet loss, time 17027ms

rtt min/avg/max/mdev = 0.916/2.071/2.747/0.539 ms

to uz vypada o neco lip..

ppp76

Testujte v tej chumelenici co je ted venku ... teda aspon u nas na severu :)

jinak diky za testy konecne sem nekdo hazi neco jineh nez domenky

ty testy? proc je tam takovej velkej rozdil rychlosti? a ty odezvy jsou pri maximalni zatezi co to da?

sel by dat test rekneme stabilne omezene tam pustit treba staci 300mb a jaky to ma odezvy ne rpi maximu ale nejakym prumeru? diky

Kolobok

Tak to je pekny :) Jsem prijemne prekvapenej, na 5 km pri tomhle pocasi supr..

rado3105

Vie mi niekto vysvetlit zmysel a pointu - vyhody pouzitia FPGA? (v jednoduchosti prosim), pocul som ze vdaka tomu sa bude dat jednotka airfiber preprogramovat na rozne ine frekvencie a bez zmeny jednotky je mozne radikalne menit fungovanie zariadenia.

FPGA je hradlové pole obsahující několik desítek tisíc elementárních logických hradel. Programováním FPGA jednoduše "drátuješ" vnitřní hradla dohromady. Každé FPGA má fixní frekvenci, bežně 50MHz a výše. Pokud se ti povede udělat logiku a zadrátovat ji do FPGA, víš, že se provede přesně 50M/s.

Oproti běžnému procesoru, kde vlastní "program" běží až na několikáté vrstvě nedokážeš přesně časovat jednotlivé operace programu na reálný čas, protože linuxové jádro není realtime a pokud je, tak to nezvládají vyšší programovací jazyky než assembler.

Když tedy potřebuješ zpracovávat QAM1024 je pro tebe jednodušší použít hradlové pole, protože se dá relativně přesně pracovat s časem oproti běžnému linuxu (třeba) kde je čas tvému programu přidělován systémem a 1us nemusí být přesně 1us a už je problém se zpracováním dat...

Vdaka, ale vyhody pouzitia? je mozne menit aj funkcie zariadenia zmenou firmwaru(airos f)? je mozna zmena na inu frekvenciu len preprogramovanim? dalsie moznosti vyuzitia - vyhody?

jap

Testujte v tej chumelenici co je ted venku ... teda aspon u nas na severu :)

jinak diky za testy konecne sem nekdo hazi neco jineh nez domenky

ty testy? proc je tam takovej velkej rozdil rychlosti? a ty odezvy jsou pri maximalni zatezi co to da?

sel by dat test rekneme stabilne omezene tam pustit treba staci 300mb a jaky to ma odezvy ne rpi maximu ale nejakym prumeru? diky

muzu zkusit, ale nejak se mi nedari omezit pasmo, ktere iperf pouzije - omoci -b to nefunguje..

a nestaci ti, ze to ma do 3ms i pri plne zatezi?

root@suchdol:~# iperf -c 192.168.1.40 -i 10 -t 86400 -b 300m

WARNING: option -b implies udp testing

------------------------------------------------------------

Client connecting to 192.168.1.40, UDP port 5001

Sending 1470 byte datagrams

UDP buffer size: 112 KByte (default)

------------------------------------------------------------

local 192.168.1.30 port 39265 connected with 192.168.1.40 port 5001

Interval Transfer Bandwidth

0.0-10.0 sec 52.4 GBytes 45.0 Gbits/sec

^C 0.0-11.1 sec 56.4 GBytes 43.5 Gbits/sec

Sent 285508 datagrams

read failed: Connection refused

WARNING: did not receive ack of last datagram after 5 tries.

jap

Tak to je pekny :) Jsem prijemne prekvapenej, na 5 km pri tomhle pocasi supr..

ja taky, novy fw tomu pomohl..

tomasbrincil

Ty hele, to pole tam je nejspíš pro modulovani dat do signálu ne?

Nebuďte paničky a pošlete tam UDP když stroje nestihaji.

Presne tak. Na nejaky strance 4 jsem posilal konkretni odkazy na sbernici po ktere komunikuje cpu a fpga pole.

Z toho cpucka to jen pretejka mezi sbernicema eth a fpga, pokud je potreba do toho hrabnout, tak se do toho hrabne. Jinak by to melo fungovat jako profi pojitka a pokud neni potreba delat vyssi zasahy, tak by latence mela byt otazkou par taktu, protoze se to bude shiftovat na jinou sirku sbernice.

tomasbrincil

Vie mi niekto vysvetlit zmysel a pointu - vyhody pouzitia FPGA? (v jednoduchosti prosim), pocul som ze vdaka tomu sa bude dat jednotka airfiber preprogramovat na rozne ine frekvencie a bez zmeny jednotky je mozne radikalne menit fungovanie zariadenia.

Vdaka, ale vyhody pouzitia? je mozne menit aj funkcie zariadenia zmenou firmwaru(airos f)? je mozna zmena na inu frekvenciu len preprogramovanim? dalsie moznosti vyuzitia - vyhody?

Ty vyhody jsou zrejme pokud znas rozdil mezi architekturou klasickeho armoveho procesoru a fpga. Ty funkce jdou menit, pole se necha bezne preprogramovat. Dela se to treba na drahych firewallech. Kde je zasadni nizka latence a velka propustnost, proste s novym fw prijde nove zadratovani logiky.

Zmenu frekvence nevim, to ti poradi Insider, urcite to jse v ramci nejakeho naladeni zmenit, ale do toho uz tolik nevidim. Jsem programator, hardwarar ale ne radioamater :

hapi

Pust tam UDP. Ten ukazuje jitter atd. Jde i omezit. Dej tam třeba minutovej test s výsledky po 10 sekundách.

jap

Pust tam UDP. Ten ukazuje jitter atd. Jde i omezit. Dej tam třeba minutovej test s výsledky po 10 sekundách.

sorry, pozdeji - prave volali z mostarny, ze uz nas cekaji..

david2006

Tak mám tu obrázky dnešního testu který jsme s Nevrhappym udělali. Výsledky má uložené on(ochutnávku ale už předkládám). Obecně při 1ms pingu se spoj pohybuje od 22Mbs (4xREP) až po 630Mbs (6xQAM). No mazec, bomba - umíráček pro jiné výrobce na krátké tratě u nás : : . Něco v TCP už nedal routr, tak se muselo omezovat víc než dá spoj pořád s 1ms latencí.

http://www.ulozto.cz/xEWzoYg/tcp-obousm ... outrem-png

http://www.ulozto.cz/x8nYoi2/tcp-odesil ... fibrem-png

http://www.ulozto.cz/xsyJBtA/tcp-send-m ... pojeni-png

http://www.ulozto.cz/xjZnGRT/tcp-zarizl ... k-siso-png

http://www.ulozto.cz/xNQoRSJ/tcp-zarizl ... so-1ms-png

http://www.ulozto.cz/xNB5ZHh/udp-obousm ... -630mb-png

http://www.ulozto.cz/xGMQAWt/udp-send-rizle-660mbs-png

http://www.ulozto.cz/xvYcLCS/udp-send-r ... nysmer-png

neverhappy

Takze po mereni s Davidem2006 mam tyto screeny.

Merili jsme asi 3 hodiny za takoveho mrholeni. Spoj ukazoval 900m. Testovani probihalo na dvou routerech. Prvni 2 jadrovy intel 3 GHz, mk verze 5.18 crack (jen pro ucely testu) a druhy dvoujadrovy Atom verze 5.20.

Pri propojeni dratem bylo spojeni v UDP stabilne na 900Mb/900Mb s packetem 10 000 byte ping 0ms. Pri TCP jednim smerem stabilne 800Mb a druhym 300Mb. Pri FD to jelo stabilne bud 260/260Mb nebo 550Mb/100Mb.

Proc ? to nevim, menil jsem disky sitove karty, atd. Sitovky byly na Motherboardu, pres PCI jsem se nedostal pres 550Mb. Takze v TCP jsem nemohli AF24 otestovat na plny vykon.

Pre AF24 (misto dratu) jsme namerili toto.

Slabina, kterou spoj ma, ze pri plnem vytizeni v UDP je ztratovost 20%, v TCP 12%. Max rychlost byla v UDP 680Mb a v TCP 660Mb

Modulace mereno v TCP, ping 10 000 byte

ta nejpomalejsi 4xpreposilany packet plna zatez 25Mb/25Mb ping cca 100ms , velka ztratovost packetu, pri orezani na 23/23Mb bez ztratovosti ping 2ms

1xSISI QPSK plna zatez 108/108 ping 22ms , stredni ztratovost packetu, pri orezani spoje 100/100Mb ping 2ms bez ztrat

2xQPSK plna zatez 216/216Mb ping 10ms ztratovost. Pri orezani na 200/200Mb ping 1 ms bez ztrat

4xQAM plna zatez 460/460Mb ping 6 ms ztratovost . Pri orezani na 440/440Mb ping 1 ms bez ztratovosti

Modulace. Ta nejvetsi myslim 6x64qam nebo jak to bylo napsany viz obrazky

neverhappy

Mereni TCP, viz obrazky.

Davidovi dekuji za prijeti, jeho cas a kafe. Po ceste zpet jsem malem zajel dva bazanty.

Muj pocit z toho pojitka je velmi dobry. Za ty penize je to luxus. Navic verim ze v nejakym firmware osetri tu ztratovost packetu pri max provozu.

Je jedno jesli navazu 1 conection nebo 100, vysledky byly stejne

Edit: Davide, nevim, cim skryvas na tech obrazkach ty mac, ale ja je prectu, asi mam dobre oci nebo dobry monitor

Kolobok

Jediny, co me desi je, cim veci sajgon v praze je tim vic je tam signalu :))))

tomasbrincil

Jediny, co me desi je, cim veci sajgon v praze je tim vic je tam signalu :))))

Absolutní odraz skrz kapky, neznáš?

hapi

mám předpokládat že když budu koukat na 700Mbit pojítko tak že uberu z něj 10% tak pojede bez PL? Proleze tam tedy 630FDX ok?

Nikde tam nevidim na těch obrázkách PL... čim jste ho měřily? UDP testy neukazujou nějaký dropnutý pakety.

blax

pri saturaci zacne chybovat jakykoliv spoj - leda ze zahazovani paketu presune na dalsi prvek v siti - napr pomoci FlowControlu.

velmi pekne to tady popisuje SummitD :-)

neverhappy

mám předpokládat že když budu koukat na 700Mbit pojítko tak že uberu z něj 10% tak pojede bez PL? Proleze tam tedy 630FDX ok?

Nikde tam nevidim na těch obrázkách PL... čim jste ho měřily? UDP testy neukazujou nějaký dropnutý pakety.

Presne jak pises. Kdyz uberes tak je to bez packet lost. Merili jsme jen bandwitch testem. Packet lost je cca 10% kdyz je spoj zatizeny na max co da, coz bylo 682Mb. Packety to ztracelo az do cca 640Mb. Na 630Mb to bylo stable. Samozrejme na treba 640-650Mb byl packet lost maly , ale byl. Mereni jsem pojal spis tak co to da bez PL. Tech 630Mb tam jede OK na tech 900m.

Pokud to beres tak ze kdyz je to 700Mb pojitko a da to 'jen 630Mb' , tak ano, nesplnuje datasheet. . Ale to snad nikdo necekal. popravde pro me bylo prekvapenim, ze to jelo tak dobre. Ja cekal strop nekde na 200Mb.

Pro me jako maleho ISP, kde mi tece max 120Mb je to dobra koupe s tim ze bych mel mit na mnoho let vystarano.

peyrak

tak jsem to dnes nasadil a jedna strana je na stožáru s 24GHz ATH spojem a to to AF z toho evidentně není nadšený :

dosměrovaný to je, ale vůbec se mi nezvedla modulace a ping skrz je jak noty na buben, spoj je na necelých 600m

zítra to zkusím napálit na držák za rohem té strojovny a uvidíme

přesunuto a už to šlape jak má, jen ta nesnášenlivost je teda dost mrzutá

« Předchozí stránka Další stránka »