Cambium ePMP 1000

[bartes]

pri 20MHz

[wirelessguy]

Teď v únoru by měl vyjít nový FW 2.x kde bude mj. k dispozici i větší výkon, aby se to srovnalo s ubnt. V některých případech je to bohužel jen o tom, že ostatní řvou na plný výkon a tady ePMP zatím ztrácí. Jinak nechápu, že ani na stole nejste schopni z toho vytlačit více než 20Mbps. To je něco špatně. Já mám malý setup (1xAP a 2xSTA), za každým prvkem malý linux PC a nastavení AP je 20MHz kanál, poměr 75/25:

root@linktester-master:~# iperf -c 10.0.0.20 -t 20 -P 4
------------------------------------------------------------
Client connecting to 10.0.0.20, TCP port 5001
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[ 5] local 10.0.0.10 port 53461 connected with 10.0.0.20 port 5001
[ 4] local 10.0.0.10 port 53459 connected with 10.0.0.20 port 5001
[ 3] local 10.0.0.10 port 53458 connected with 10.0.0.20 port 5001
[ 6] local 10.0.0.10 port 53462 connected with 10.0.0.20 port 5001
[ ID] Interval Transfer Bandwidth
[ 6] 0.0-20.0 sec 49.8 MBytes 20.9 Mbits/sec
[ 4] 0.0-20.0 sec 52.2 MBytes 21.9 Mbits/sec
[ 5] 0.0-20.1 sec 52.8 MBytes 22.0 Mbits/sec
[ 3] 0.0-20.1 sec 51.5 MBytes 21.5 Mbits/sec
[SUM] 0.0-20.1 sec 206 MBytes 86.1 Mbits/sec

A pro jednu TCP session:
root@linktester-master:~# iperf -c 10.0.0.20 -t 20
------------------------------------------------------------
Client connecting to 10.0.0.20, TCP port 5001
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[ 3] local 10.0.0.10 port 53464 connected with 10.0.0.20 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-20.0 sec 201 MBytes 84.2 Mbits/sec

Moc velký rozdíl to tedy není.

A teď uplink:

root@linktester-slave:~# iperf -c 10.0.0.10 -t 20 -P 4 -p 5500
------------------------------------------------------------
Client connecting to 10.0.0.10, TCP port 5500
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[ 6] local 10.0.0.20 port 55105 connected with 10.0.0.10 port 5500
[ 3] local 10.0.0.20 port 55102 connected with 10.0.0.10 port 5500
[ 5] local 10.0.0.20 port 55104 connected with 10.0.0.10 port 5500
[ 4] local 10.0.0.20 port 55103 connected with 10.0.0.10 port 5500
[ ID] Interval Transfer Bandwidth
[ 5] 0.0-20.1 sec 16.2 MBytes 6.78 Mbits/sec
[ 3] 0.0-20.3 sec 15.6 MBytes 6.47 Mbits/sec
[ 4] 0.0-20.3 sec 16.6 MBytes 6.87 Mbits/sec
[ 6] 0.0-20.4 sec 12.9 MBytes 5.29 Mbits/sec
[SUM] 0.0-20.4 sec 61.4 MBytes 25.2 Mbits/sec

Takže jestli z toho někdo dostal tuto hodnotu, tak nejspíš testoval uplink, který opravdu při tomto nastavení více nedá. Takže to se pak nedivím. Chce to zkusit oba směry
V součtu pak máme 85+25 = 110 Mbps (pochopitelně jsou toto peak testy a pro každý směr zvlášť).

[wirelessguy]

A ještě k té latenci - to přece není problém, zabiják a problém je jitter.

V klidu je uplink latence:

root@linktester-slave:~# ping 10.0.0.10
PING 10.0.0.10 (10.0.0.10) 56(84) bytes of data.
64 bytes from 10.0.0.10: icmp_req=1 ttl=64 time=13.8 ms
64 bytes from 10.0.0.10: icmp_req=2 ttl=64 time=12.6 ms
64 bytes from 10.0.0.10: icmp_req=3 ttl=64 time=10.7 ms
64 bytes from 10.0.0.10: icmp_req=4 ttl=64 time=13.8 ms
64 bytes from 10.0.0.10: icmp_req=5 ttl=64 time=11.8 ms
64 bytes from 10.0.0.10: icmp_req=6 ttl=64 time=10.5 ms
64 bytes from 10.0.0.10: icmp_req=7 ttl=64 time=13.8 ms
64 bytes from 10.0.0.10: icmp_req=8 ttl=64 time=11.8 ms
64 bytes from 10.0.0.10: icmp_req=9 ttl=64 time=14.8 ms
64 bytes from 10.0.0.10: icmp_req=10 ttl=64 time=12.8 ms
Typicky nějakých ~13ms.

Downlink pak:
root@linktester-master:~# ping 10.0.0.20
PING 10.0.0.20 (10.0.0.20) 56(84) bytes of data.
64 bytes from 10.0.0.20: icmp_req=1 ttl=64 time=14.8 ms
64 bytes from 10.0.0.20: icmp_req=2 ttl=64 time=14.3 ms
64 bytes from 10.0.0.20: icmp_req=3 ttl=64 time=17.7 ms
64 bytes from 10.0.0.20: icmp_req=4 ttl=64 time=15.7 ms
64 bytes from 10.0.0.20: icmp_req=5 ttl=64 time=18.7 ms
64 bytes from 10.0.0.20: icmp_req=6 ttl=64 time=16.7 ms
64 bytes from 10.0.0.20: icmp_req=7 ttl=64 time=14.7 ms
64 bytes from 10.0.0.20: icmp_req=8 ttl=64 time=17.7 ms
64 bytes from 10.0.0.20: icmp_req=9 ttl=64 time=15.9 ms
64 bytes from 10.0.0.20: icmp_req=10 ttl=64 time=14.6 ms

Tedy typicky nějakých 17ms.

[Hatatitla]

A ktomu pripočítaj ďalších 5ms niekde po sieti a máme ztoho pekných 22 ms , niektorí zákazníci by ma za to asi roztrhali .

[wirelessguy]

A důvod?

[Kess]

Hezké meření..začínám mít pocit že naše jednotky jsou nějaké zakleté, taková čísla ať už v propustnosti nebo latenci sem neviděl ani na stole, kde cokoliv jiného běhalo jak má. Uplink testovaný určitě nebyl, už jen proto že to v obou směrech fungovalo +- stejně rychle. A stejné výsledky podával iperf, ftp přenosy, streamování, cokliv. Možná by nebylo od věci vyzkoušet jiné jednotky, jeslti prostě nemáme pech na nějaké né úplně ok kusy, ale obávám se že s tím nikdo nebude chtít ztrácet další čas a peníze. A "oprava" stylem přidáme výkon je asi tak přesně to, co dokázalo ubnt, aneb že jsme se všichni setkali na max výkonu a doufáme že se to skrz aspoň nějak propálí.

No každopádně jsem pár dalších kliošů naházel různě po síti na nasimulování jakž takž reálného PTMP spojení. Jsou v rozmezí cca 300-1000m. No a nepomohlo to naprosto ničemu, funguje to pořád stejně, možná o chlup líp, okolo 25 Mbit na té nejbližší jednotce u mě na baráku, ale ty vzdálenejší vyždímají 10-15Mbit max. A to to ještě musím poslat lehce mimo klasické pásmo 5,5-5,7Ghz, jinak to jde do kopru úplně.

Zkusím tomu dát ještě šanci až bude chvilka a rozchodit to nějak rozumně aspoň na stole, jinak to ani nemá cenu do toho bordelu co je tady venku tahat. Tohle bylo spíš přání vedení že to třeba bude fungovat když se to nebude samo rušit odrazy od stěn atd.

[menicks]

Po 1.3.4 celkem v klidu projede 40/10 výpadky byli jakž takž vyřešeny. Ale každopádně na víc jak 600m jsou s tím problémy. Chělo by to lepší klienty se ziskovější a směrovější anténou :/

[wirelessguy]

Po 1.3.4 celkem v klidu projede 40/10 výpadky byli jakž takž vyřešeny. Ale každopádně na víc jak 600m jsou s tím problémy. Chělo by to lepší klienty se ziskovější a směrovější anténou :/

OK, to je dobře, že je alespoň nějaký posun. Vydržte do 21.2., pokud to dobře půjde, měli by vydat další FW, tak budeme doufat
Jinak k těm výsledkům na stole - kdybych to z toho nedostal, tak to sem ani nepíšu. Ale je to výsledek na stole a ne v reálu v tom bordelu. Taky nejsem zastáncem vysokých výkonů, ale došlo to tak daleko, že kdo víc křičí, ten víc dostane. Už jsou k dispozici i konektorovaní klienti, takže tam se nechá systémový zisk nahnat anténou a ne hrubým TX výkonem.

[KoZLiCeK]

Takže za ty prachy na....

[wirelessguy]

Takže za ty prachy na....

Ano, konstruktivní komentáře jsou vždy vítány

[stouracpetr]

Takže za ty prachy na....

Ano, konstruktivní komentáře jsou vždy vítány

sektor po uprave x.JPG (63.45 KiB) Zobrazeno 4101 x

Jeden znamy ,nespokojeny s parametry teto sektorove anteny urcene k CAMBIU mne ji zaslal na premereni .Antena je kmitoctove zavisla-signal blizkych a vzdalenych klientu v danem smeru je znacne rozdilny nejen ve smyslu vzdalenosti od AP,ale navic se uroven lisi -radove 10 dB-podle kmitoctu a polarizace.
Na obrazku je uprava ,,co dum dal,, -casti DPS ze starych dobrych Octagonu... Ted uz se chova jako standartni sektorova antena se ziskem cca 14 dBi a plynulym poklesem urovne signalu v elevaci i azimutu.

Pokud se u teto anteny setkate s podobnymi potizemi,nejedna se o vadu,ale o vlastnost.

[netnz]

zdravim vas

toto vlakno som si uz par krat precital a snazim sa zistit, v akom stave je momentalne empm 1000, myslim ze dnes vysiel fw 1.4.3.
Ma to niekto nasade v reale? Ma zmysel si objednat zapozicku?
Dik za reakcie.

[menicks]

Má.

[netnz]

Dost strucna odpoved Mozem sa dozvediet aj viac?

[menicks]

Co konkretně?