Problem SXT vs. SXTsq vs. DISC

honzam

furt stejně nahovno. Sice použitelné už to je, ale NV2 je u ARM procesorů nejpomalejší protokol...

myghael

to používáš lhg a ne disky? Vlastně je to jedno když všechno stojí stejně a to i sxtsq.

Jo. LHG je osvědčené a lidem se líbí design. První DISCy nám všechny do dvou měsíců popraskaly, takže jsme je reklamovali a přestali montovat. Znovu jsme jich pár na zkoušku koupili a nasadili až nedávno, pokud do jara nepopraskají, budeme používat i ty.

magic

Zaznamenali jste někdo podobné potíže s ARM jednotkama (DISC ac, SXTsq ac)?

Pokud používám na AP protokol Nstreme, tak se jednotka zasekne a pomůže jen její restart. Někdy vydrží celý den. Někdy jen pár hodin nebo minut. Frekvence a ani nastavení Nstreme na to nemá vliv (Framer policy - none i best fit). Jiné než ARM jednotky se takto nechovají. Protokol 802.11 funguje normálně, ale jsou lokality kde je lepší použít nstreme.

Verze na AP i na jednotkách vyzkoušeny postupně všechny od 6.42.2 po 6.43.2.

Má s tím někdo zkušenost? Je to nějakou chybou v nastavení?

pepulis

Zaznamenali jste někdo podobné potíže s ARM jednotkama (DISC ac, SXTsq ac)?

Pokud používám na AP protokol Nstreme, tak se jednotka zasekne a pomůže jen její restart. Někdy vydrží celý den. Někdy jen pár hodin nebo minut. Frekvence a ani nastavení Nstreme na to nemá vliv (Framer policy - none i best fit). Jiné než ARM jednotky se takto nechovají. Protokol 802.11 funguje normálně, ale jsou lokality kde je lepší použít nstreme.

Verze na AP i na jednotkách vyzkoušeny postupně všechny od 6.42.2 po 6.43.2.

Má s tím někdo zkušenost? Je to nějakou chybou v nastavení?

Jak poznate zaseknuti jednotky? To nahlasi klient? Nic takoveho zatim nikde nepozoruji.

magic

Jednotka se odpojí od AP a dokud klient nevypne z elektřiny, tak se znovu nepřipojí.

pepulis

Jednotka se odpojí od AP a dokud klient nevypne z elektřiny, tak se znovu nepřipojí.

Tak tohle nepozoruji vubec / nikdo nic nehlasil.

hapi

vyměnit.

magic

Vyměnit co? Jednotky to dělají všechny bez výjimky. V současnosti cca 30. Mám podezření na nějaké jiné nastavení, ale myslím, že většina je defaultní. Problém přišel s novými verzemi a ARM. Staré mipsbe bez problémů.

mario

Ja na ARM pozoruji mikro výpadky oproti mipsbe, radio drží ale data neprocházi. Bavím se o 802.11, nv2 drží, ale rychlost zase nižší.

honzam

Vyměnit co? Jednotky to dělají všechny bez výjimky. V současnosti cca 30. Mám podezření na nějaké jiné nastavení, ale myslím, že většina je defaultní. Problém přišel s novými verzemi a ARM. Staré mipsbe bez problémů.

Nevím no. Jediný problém který tam je tak NV2. To Mikrotik mlčí jak partyzán i když všichni na foru nadávají.

Ohledně nstreme - máme na spoji uptime víc jak měsíc. Což je doba od posledního upgradu. Je tam 6.43.2. Na obou stranách ARM hardware

k3ny

nejaky zmeny? Nepozoruje nekdo problemy ve spojitosti s AC na AP a u klienta, zarizeni se restartuje. Jaky pouzivate aktualne FW na ARM wireless zarizenich.

honzam

Ohledně zasekávání - opravdu se to děje a je to náhodné. U protokolu NV2 jednou za čas dojde k zaseknutí klienta že pomůže jenom odpojení od el.

Děje se to i s verzí 6.43.4.

Možná to řeší 6.43.7 ale na nějaké soudy je ještě brzo. Není tak dlouho venku

hapi

měly jsme dlouho 6.43.4 a nevšim sem si nikde zasekávání. Teď jedeme 6.43.7 a pokud má někdo spoj na těch 4core ARMech... totální mazec v závislosti na okolním rušení samozřejmě.

petrs_

měly jsme dlouho 6.43.4 a nevšim sem si nikde zasekávání. Teď jedeme 6.43.7 a pokud má někdo spoj na těch 4core ARMech... totální mazec v závislosti na okolním rušení samozřejmě.

Co myslíš přesně tím "totální mazec"?

whef

Taky by mne to zajímalo, co je totální mazec, ale jelikož to píše Hapi, tak to asi jede dobře :) čemuž se mi nechce věřit.

mpcz

Asi ani tak nezáleží na tom, kdo to píše, (kolega Hapi je samozřejmě vyjímkou), ale na tom, kde to je. Je to třeba Praha 6 nebo zapadlá dědinka někde na rovině na Hané? mpcz, 16.12.2018

hapi

sektor s RB921GS, 15 klientů, protokol 802.11. režim only-N, 20MHz. Ti co mají Nkový klienty tlačí 70Mbit, ti co mají ARM-AC tlačí 95-100Mbit. U posledního klienta na jeho PC naměřeno 95Mbit (fast ethernet).

disc lite5 ac proti sobě na ptp spoji 800m. only-AC, 802.11, 20MHz. Btest mezi jednotkama 120Mbit.

Všechny testy jsou prováděný na 1x TCP. Žádný UDP nebo hodně TCP spojení.

Tohle dřív nebylo možný ani náhodou. Nicméně problém s NV2 a starými klienty (CPU 400MHz a níž) přetrvává dál.

Samozřejmě že ne všude to funguje nicméně oproti předchozím verzím (pod 6.43) je to značnej rozdíl. U většiny klientů co jsme byly na servisech opravách nebo přípojkách tak pod 50Mbit nenaměříme a to je v cestě ještě domácí wifina takže to považuju za velkej úspěch. Pokud je zarušenej kanál tak nepomůže nic, to je snad jasný u všech technologií.

To samí platí o síle signálu. Pokud maji klienti -60dB tak smůla jako všude. Výše uvedený sektor má nejhoršího klienta se signálem -48dB.

basty

poznatek, dish AC proti sxtsq ac arm.

Pouze zalozni spoj na LHG, testovani v indooru 80MHz.

UDP (neslo jinak)

802.11 cca 580 Mbps

nv2 a nstream cca 230M.

Zajimave ze jede 802.11 takto lepe... Ale pri 20 a 40MHz je zase lepsi nstream nez 802.11.

hapi

protože UDP.

tak si testoval na LHG nebo dish proti sxt?

Jako ok, někdo to potvrdil nicméně proč 80MHz kanál kterej je venku k ničemu? i 40MHz udělá větší bordel s menšim poměrem výkon/obsazenej prostor.

gemb

protože UDP.

tak si testoval na LHG nebo dish proti sxt?

Jako ok, někdo to potvrdil nicméně proč 80MHz kanál kterej je venku k ničemu? i 40MHz udělá větší bordel s menšim poměrem výkon/obsazenej prostor.

80MHz je primarne pre starnet apod.

Schvalne by bolo dobre vediet rozdiel medzi prenosovkou na 40 vs 80MHz kanale. tych 250Mbit sa musi dat spravit na 40MHz (za predpokladu cistoty freq)

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