Problem SXT vs. SXTsq vs. DISC

hapi

žádná změna, auto tam bylo předtím. Tahle chyba tam je už několik měsíců a lidi jí i postujou na mk forum. Teď řešim jinej problém. Globální upgrade na 6.44 vyřadil pár hap (ac) lite ve smyslu žijou ale nejsou připojený ke capsmanu a nedá se na ně dostat.... super kuva. Takhle to dopadá když mikrotik nutí testery aby co nejrychleji postovaly chyby aby to co nejrychleji vyšlo což bylo právě u 6.44.

honzam

6.44 byla právě verze která vyšla snad nejpomaleji ze všech co znám, takže na to bych to nesázel.

Měla asi 75beta verzí. Pak 4 RC verze a teprve pak vyšlá ostrá

hapi

<--- ia0 -->6-44-rate-fail.png<--- ia0 -->

super ne?

okoun

je to jen Tx, Rx je dobrá, zkus na CPE dát také only n a pokud to bude furt stejný tak bych to normálně reportoval....

hapi

už jim nic reportovat nebudu. Poslední report byl že scan-list=5500-5700 se nepřipojí na kanál 5700 ale 5500-5720 už jo a ty kokoti si to ani nedokázaly vyzkoušet a chtějí po mě suppout a podobný kraviny a na to fakt nemám čas.

hapi

hmm...

omnitik ac + sxtsq ac... vše 6.44. Za pár hodin se z toho stane sotva 2Mbit linka. Stačí vykopnout a šup, už jede 110-120Mbit.

dagus

Předpokládám, že to dle svých slov to ale reportovat nebudeš :. Trochu smutné je, že si to nemůže Mikrotik sám trochu otestovat. Jinak dobrej typ na hledání případného problémů. Na jiném klientovi to dělalo taky? Jakože jestli to dělat ap, nebo cl.

hapi

otestovat si to nemůžou. Těžko je někdo donutí k použití prvního SXT, SXT lite5, SXT AC a SXT ARM aby si to otestovaly spolu na jednom sektoru. Jo ok, arm teď jede zdá se podstatně lépe ale o to hůř jedou věci s 400MHz procákem což jsou RB711 a první SXT. Ty dostávaji totálně na prdel. Je taky fakt že je třeba uvážit že ty jednotky maji dneska už hodně nalítáno a nemuseji bejt OK a rozdrbou celej sektor. To bohužel vyloučit nemůžu a bude to chtít obměnu.

ladik

hmm...

omnitik ac + sxtsq ac... vše 6.44. Za pár hodin se z toho stane sotva 2Mbit linka. Stačí vykopnout a šup, už jede 110-120Mbit.

Tak toto potvrzuji, úlpně náhodně jsem přišel na to, že OmniTik AC sice přenáší data ale šíleně pomalu.

Přípoj je FD 360Mbit a test propustnosti do max 2Mbit, prostě katastrofa, pak po restartu OmniTiku měl btest 360Mbit/360Mbit.

Teď jen jak zajistit, aby to bylo vždy OK, těžko se to zjišťuje jinak než btestem, protože ping jede normálně.

Tak asi bude probíhat denně třeba nad ránem nucený restart Omnitiku, jiné řešení mne nenapadá, ale co když se to stane i v tom čase do 24hod?

Škoda, že při restartu OmniTiku se nerestartují samy i připojené zařízení na POE to mne štve.

hapi

čoveče, zatim mi to od tý doby postu neudělalo a nemůžu si boha vzpomenout co sem změnil. Matně si vzpomínám že tam bylo only-n a teď tam je N/AC.

ladik

To je pěkné, ale mě to udělalo na eth only, protože, zrovna na tomto sajtu wifi z OmniTiku mám vypnuto resp. vůbec není nakonfigurováno.

pepulis

To je pěkné, ale mě to udělalo na eth only, protože, zrovna na tomto sajtu wifi z OmniTiku mám vypnuto resp. vůbec není nakonfigurováno.

Tak to bude chyba asi nekde jinde. Omnitiky mam taky a dostanu k nim max. rychlost, co je tam privedena. Vsude je verze 6.44. Pouze u jednoho omnitiku mi to po upgrade na 6.44 zacalo z niceho nic psat do logu: port received packet with own address as source address nebo neco v tom smyslu a omnitik se mi vzdy na nejakou dobu odmlcel. Nakonec se mi tam podarilo dostat, zmenit konfiguraci a vse jede.

ladik

Nemyslím si, že chyba bude někde jinde, když jsem restartoval pouze toho jediného OmniTika, na který se dělal test, nic jiného se nerestartovalo a ani nenastavovalo. Asi náhoda...

coolerman1

pozoruje niekto nepravidelny uplne nahodny timeout ? Ci tam je traffic a ci nie ,raz za cas je timeout niekedz par krat po sebe

AP RBM11+R11E-5HACD 6.43.4 + antrena RF horn 30 stupnov - klienti 1 SXT N/AC 6.43.4 ,klient 2 sxt SQ 6.44 , protocol 802.11 , vzdialenost klientov do 500m

okoun

jj bohužel toto je hodně dlouho není to problém posledních verzí, jako naštestí se to stane u jednoho zákazníka třeba jen jednou za týden max, řekl bych že to je nějaký watchdog jejich interní či co :(

hapi

o ničem takovym nevim a většinou to dělá 802.11 když nějaký klient lehne na trafic a neni zrovna v pořádku připojenej.

okoun

on to kolikrát ani není moc vidět v dohledu musíš opravdu takto pingat a ještě se do toho strefit :)

krásně to je však vidět na pppoe session že prostě vypadne u jednoho zákazníka ze sektoru, přitom zákazník má -45 signálu a 100% ccq, je to prostě náhodné :)

coolerman1

on to kolikrát ani není moc vidět v dohledu musíš opravdu takto pingat a ještě se do toho strefit :)

krásně to je však vidět na pppoe session že prostě vypadne u jednoho zákazníka ze sektoru, přitom zákazník má -45 signálu a 100% ccq, je to prostě náhodné :)

presne tak ,mam pri sebe taketo dva sektory a jeden to robi menej a jeden castejsie,skusal som aj preladit avsak nepomaha ,problem je v tom ,ze pri starsich verziach FW sa to

nestavalo

inak to ccq pokial je klient neaktivny ma CCQ 67/70 cca a ak zacnu tiect data tak sa zvysi na 94/99 a pri tom je priama viditelnost na 500m

je asi cas prejst na UBNT

crazyape

on to kolikrát ani není moc vidět v dohledu musíš opravdu takto pingat a ještě se do toho strefit :)

krásně to je však vidět na pppoe session že prostě vypadne u jednoho zákazníka ze sektoru, přitom zákazník má -45 signálu a 100% ccq, je to prostě náhodné :)

presne tak ,mam pri sebe taketo dva sektory a jeden to robi menej a jeden castejsie,skusal som aj preladit avsak nepomaha ,problem je v tom ,ze pri starsich verziach FW sa to

nestavalo

inak to ccq pokial je klient neaktivny ma CCQ 67/70 cca a ak zacnu tiect data tak sa zvysi na 94/99 a pri tom je priama viditelnost na 500m

je asi cas prejst na UBNT

Ten problém o kterém se bavíte je tady tohle? Viz. níže? Klient je stale pripojen na AP ale 30s neproteče žádný provoz? Řešil jsem to ted na jednom ARM ptp LHG XL AC vs LHG XL tam to delalo i 10x do hodiny tam jsem vymenil obe strany za klasicke LHG v Nku taky XL vs malé a propustnost vylezla ze 40Mbps na 70Mbps a problem zmizel (stejny kanal, stejne nastavení nv2 stejny firmware. A todle víz níže je z RB922UAGS v hornu 30st. Je na nem 7 lidi vscihni maji DICS 5 nebo LHG5 signal nejhorsi -52/55. Všichni CCQ90%+ udela to na 1TCP kolem 60-70Mbps na kterehokoliv z nich ale vsichni klienti na něm mají občas takový krátký výpadek přezto, že rádio je bezrátově spojené.

vystrizek2.PNGVýstřižek.PNG

honzam

Řešil jsem to ted na jednom ARM ptp LHG XL AC vs LHG XL tam to delalo i 10x do hodiny tam jsem vymenil obe strany za klasicke LHG v Nku taky XL vs malé a propustnost vylezla ze 40Mbps na 70Mbps a problem zmizel (stejny kanal, stejne nastavení nv2 stejny firmware.

A jaký firmware? To nejdůležitější nenapíšeš

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