i4wifi.cz

Blog i4wifi

Rocket - reálný test v zarušeném prostředí

22.01.2010 14:20

Už je to více než tři měsíce co je na trhu k dispozici nová řada produktů Ubiquiti podporující protokol 802.11n s označením Airmax. Někteří z vás je již používají. Jiní testují. A právě jeden z poskytovatelů na Slovensku sadu Rocket M5 s anténou RocketDish pro nás otestoval. Výsledek je velmi objektivní a je nutné přihlédnout k faktu, že pro testování nebyla k dispozici finální verze AirOS a spoj byl provozován v opravdu velmi zarušeném prostředí.

Níže již samotný test:

Výsledky testovania P2P spoja - Rocket-5M

Schéma spoja

Spoj P2P s použitím zariadení Ubiquity Rocket-5M bol testovaný v podmienkach mesta s

relatívne zarušeným 5,4GHz spektrom na vzdialenosti cca 2,4 km. Medzi bodmi, kde boli

umiestnené zariadenia je priama viditeľnosť, Fresnelova zóna je bez prekážok. Samotné zariadenia boli umiestnene na relatívne vysokých budovách - 9. poschodí na jednej strane a 13. poschodí na strane druhej. Na screenshotoch sú výsledky "Site survey" na strane AP a na strane SM:

Pre testovanie bol vybraný kanál 112 (5560MHz) ako najvhodnejší z toho dôvodu, že mal

odstup od použitých kanálov s vyššou úrovňou signálu minimálne 40MHz z každej strany (viď.

screenshoty). Testovanie prenosov so šírkou pásma 40MHz z dôvodu rušenia nebolo možné, pri testovacej prevádzke boli kapacita spoja a oneskorenie veľmi nestabilné.

Takisto kvôli rušeniam bol zvolený nižší MCS index - 11 (QAM16, ½ coding rate), pri vyššej hodnote spoj začínal byť nestabilný v zmysle prenosovej kapacity a latencie. ACK timeout bol nastavený fixne na 41 (2400m + 10% rezerva). Spoj sa testoval so zapnutým AirMax, pri vypnutí spoj začínal byť nestabilným, vznikal aj "packet loss". Pri testoch bola použitá verzia firmware v5.1-beta.3207 na oboch zariadeniach Spoj sa testoval ako transparentný L2 transport v schéme:

Konfigurácia PC1: C2D E4600 2.4GHz/2GB RAM/Intel Gigabit 82541PI NIC na PCIe

OS: 64bit Ubuntu Server 9.10

Konfigurácia PC2: P4 D 3.0 Ghz/2GB RAM/ Broadcom BCM5788 Gigabit onboard

OS: 32bit Ubuntu server 9.04

Ako zdroj dátového toku pre zaťaženie spoja boli použite nástroje iperf, netperf, hping3; boli použité TCP a UDP prenosy, v prípade netperf boli skúšané aj simultánne prenosy viacerých dátových tokov TCP, takisto prenos ICMP s veľkými paketmi. Dlhodobý monitoring prenosu bol zabezpečený systémom Zabbix 1.8 na PC1, realtime hodnoty sa monitorovali pomocou iptraf/bwm-ng na PC1 a iftop na PC2.

Dosiahnuté výsledky

Stabilita zariadení - s dodávaným fw verzie 5.0.2 zariadenia niekoľko krát prestali odpovedať na ethernet rozhraní (2x AP a 1x SM), pričom stále boli dostupne cez rádio rozhranie (v prípade SM nemám overene). SM zmrzlo pri zmene nastavení a následnom reštarte - pravdepodobne "bug" vo web rozhraní. Opätovný pokus o nasimulovanie rovnakého stavu bol neúspešný. V logu pred reštartom zariadenia nájdeme nasledovné záznamy:

....... [predchádzajúce záznamy]

Dec 16 10:22:40 10.253.99.11 init: init: process '/bin/boa -d' (pid 2114) exited. Scheduling for restart.

Dec 16 10:22:40 10.253.99.11 init: init: process '/bin/tinysnmpd /etc/snmp.conf /lib/tinysnmp' (pid 2117)

exited. Scheduling for restart.

Dec 16 10:25:08 10.253.99.11 boa[2951]: Authentication successful for ubnt from 10.253.99.1

Dec 16 10:25:29 10.253.99.11 init: init: reloading /etc/inittab

Dec 16 10:25:29 10.253.99.11 dropbear[2952]: premature exit: Terminated by signal

Dec 16 10:25:29 10.253.99.11 init: init: process '/bin/dropbear -F -d /etc/persistent/dropbear_dss_host_key -r

/etc/persistent/dropbear_rsa_host_key -p 22' (pid 2952)

Dec 16 10:25:29 10.253.99.11 boa[2951]: caught SIGTERM, starting shutdown

Pri ďalšom zamrznutí AP sa nám podarilo dostať na "ssh shell" cez rádiolink, zaujímavé však je, že v tom stave zariadenie odpovedalo na ARP - PC1 malo jeho v arp tabuľke, aj samotne AP "videlo" PC1 a PC2:

XM.v5.0# cat /proc/net/arp

IP address HW type Flags HW address Mask Device

10.253.99.2 0x1 0x2 00:15:6D:E6:2C:F8 * br0

10.253.99.1 0x1 0x0 00:1B:21:29:A7:D6 * br0

ale na dotaz ping z AP na PC1 sme nedostali odpoveď, SM a PC2 sa pingovali bez problémov, pričom ethernet rozhranie AP nebolo úplné neaktívne, bolo vidno CDP rámce:

root@ubuntu:~# tcpdump -i eth1 -nvve -c 1000 -s0

tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes

14:50:15.565285 00:15:6d:e6:2c:f8 > 01:00:0c:cc:cc:cc, 802.3, length 112: LLC, dsap SNAP (0xaa)

Individual, ssap SNAP (0xaa) Command, ctrl 0x03: oui Cisco (0x00000c), pid CDP (0x2000): CDPv1, ttl: 120s, chec

ksum: 376 (unverified), length 90

Device-ID (0x01), length: 4 bytes: 'UBNT'

Address (0x02), length: 22 bytes: IPv4 (2) 10.253.99.11 IPv4 (1) 169.254.44.248

Capability (0x04), length: 4 bytes: (0x00000001): Router

Version String (0x05), length: 33 bytes:

XM.ar7240.v5.0.2.2956.091023.1759

Platform (0x06), length: 3 bytes: 'R5N'

14:50:23.983877 00:1b:21:29:a7:d6 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4

(len 4), Request who-has 10.253.99.11 tell 10.253.99.1, length 28

14:50:24.983839 00:1b:21:29:a7:d6 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4

(len 4), Request who-has 10.253.99.11 tell 10.253.99.1, length 28

14:50:25.983839 00:1b:21:29:a7:d6 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4

(len 4), Request who-has 10.253.99.11 tell 10.253.99.1, length 28

14:50:26.533836 00:1b:21:29:a7:d6 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4

(len 4), Request who-has 10.253.99.10 tell 10.253.99.1, length 28

14:50:26.741191 00:15:6d:e6:1f:87 > 01:00:0c:cc:cc:cc, 802.3, length 110: LLC, dsap SNAP (0xaa)

Individual, ssap SNAP (0xaa) Command, ctrl 0x03: oui Cisco (0x00000c), pid CDP (0x2000): CDPv1, ttl:

120s, checksum: 376 (unverified), length 88

Device-ID (0x01), length: 4 bytes: 'UBNT'

Address (0x02), length: 22 bytes: IPv4 (2) 10.253.99.10 IPv4 (1) 169.254.31.135

Capability (0x04), length: 4 bytes: (0x00000001): Router

Version String (0x05), length: 31 bytes:

XM.ar7240.v5.0.2386.090716.1502

Platform (0x06), length: 3 bytes: 'R5N'

14:50:27.503840 00:1b:21:29:a7:d6 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4

(len 4), Request who-has 10.253.99.11 tell 10.253.99.1, length 28

14:50:27.533833 00:1b:21:29:a7:d6 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4

(len 4), Request who-has 10.253.99.10 tell 10.253.99.1, length 28

14:50:28.502592 00:1b:21:29:a7:d6 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4

(len 4), Request who-has 10.253.99.11 tell 10.253.99.1, length 28

14:50:28.533834 00:1b:21:29:a7:d6 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4

(len 4), Request who-has 10.253.99.10 tell 10.253.99.1, length 28

14:50:29.502592 00:1b:21:29:a7:d6 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4

(len 4), Request who-has 10.253.99.11 tell 10.253.99.1, length 28

14:50:30.052588 00:1b:21:29:a7:d6 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4

(len 4), Request who-has 10.253.99.10 tell 10.253.99.1, length 28

14:50:31.052599 00:1b:21:29:a7:d6 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4

(len 4), Request who-has 10.253.99.10 tell 10.253.99.1, length 28

14:50:32.052590 00:1b:21:29:a7:d6 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4

(len 4), Request who-has 10.253.99.10 tell 10.253.99.1, length 28

14 packets captured

14 packets received by filter

0 packets dropped by kernel

Up/down ethernet rozhrania na AP nepomohlo, bol nutný reboot zariadenia:

XM.v5.0# ifconfig eth0_real down; sleep 5; ifconfig eth0_real up; ifconfig eth0_real

eth0_real Link encap:Ethernet HWaddr 00:15:6D:E7:1F:87

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:9544673 errors:3 dropped:2 overruns:0 frame:2

TX packets:4178745 errors:0 dropped:0 overruns:30787 carrier:0

collisions:0 txqueuelen:1000

RX bytes:308618565 (294.3 MiB) TX bytes:965695372 (920.9 MiB)

XM.v5.0# ping 10.253.99.1

PING 10.253.99.1 (10.253.99.1): 56 data bytes

--- 10.253.99.1 ping statistics ---

3 packets transmitted, 0 packets received, 100% packet loss

XM.v5.0# arping -I br0 10.253.99.1

ARPING to 10.253.99.1 from 10.253.99.10 via br0

Sent 3 probe(s) (3 broadcast(s))

Received 0 reply (0 request(s), 0 broadcast(s))

XM.v5.0# arping -I eth0_real 10.253.99.1

ARPING to 10.253.99.1 from 10.253.99.10 via eth0_real

Sent 3 probe(s) (3 broadcast(s))

Received 0 reply (0 request(s), 0 broadcast(s))

Počas testovania problém pravdepodobne odstránený použitím beta verzie 5.1 firmware z oficiálneho fóra Ubiquity. S použitím beta verzie spoj bežal nepretržite cca. 2 týždne počas sviatkov bez potreby reštartu.

V ďalšom texte používam výraz "downlink" v zmysle smeru AP -> SM a "uplink" v zmysle SM -> AP. Na nezaťaženom spoji sa latencia pohybovala na úrovni 1 - 4ms. Testy priepustnosti a latencie spoja sa robili primárne pomocou programov iperf a netperf. Testy s použitím TCP dátového toku: priemerná rýchlosť na downlinku 20Mbit/s, uplinku - 30Mbit/s, maximálna: downlink - 66Mbit/s, uplink - 31Mbit/s. Priemerná latencia spoja - 166ms, v špici do 460ms, relatívne vysoký packet loss v realtime meraniach počas testu (ping z PC1 na PC2) - do 10-15%.

Ďalej uvedené grafy zo Zabbix'u pre TCP test.

Pri realtime monitoringu pomocou bwm-ng na eth NIC PC1 sú zaznamenané veľké výkyvy v rýchlosti prenosu, ktoré nie sú viditeľné v dátach monitorovacieho systému, radovo do 10-15Mbit/s od priemernej rýchlosti. Subjektívny názor - pre prenos TCP by dosť pomohla priorizácia a rescheduling malých TCP ACK paketov.

Pri prenose UDP priemerná rýchlosť bola 38/14 Mbit/s (down/up), latencia spoja cca. 50ms so zriedkavými špicami na 150-200ms, niekedy vybehol packet loss pingu z PC1 na PC2. Celkovo sa rýchlosť držala podstatne lepšie ako v prípade TCP dátového toku, ale museli sme umelo obmedziť dátové toky v oboch smeroch z toho dôvodu, že bez obmedzenia testovacie programy začínali generovať wirespeed toky dát, čo viedlo k úplnej strate kontroly nad spojom - prestávali odpovedať zariadenia. Pri zvyšovaní traffiku nad uvedené avg hodnoty začínala rapídne stúpať latencia spoja a packet loss, preto tieto priemerné hodnoty možno považovať za maximálne.

Testy priepustnosti ICMP traffikom zodpovedali výsledkom UDP testov. Žiaľ nemali sme možnosť otestovať zariadenia v menej zarušenom prostredí - pravdepodobne by sme v takom prípade dosiahli lepšie výsledky. Počas zostavovania tohto reportu bola vydaná verzia 5.1 stable firmware, v changelogu bolo dosť zaujímavých zmien a bugfixov - žiaľ zariadenia sme mali už demontovane a zabalene.

Celkový subjektívny pocit zo zariadení je nasledovný - stále ešte dosť nestabilné, čo sa dá očakávať od nového produktu. Kvôli relatívne vysokej nestabilite a latencii spoja nemôžeme použiť tieto zariadenia na naše účely (feedovanie menších PoP'ov). Použiteľné pravdepodobne v menej zarušenom prostredí.

Obrázky instalace z místa testu: