alcoma ping problémy?

[okoun]

Pozoruji všude kde mám spoje alcomy že tam dochází skrze ten spoj k velmi malému PL, ale fakt malemu a náhodilému, nevíte v čem by mohl být problém? Wifi spoje jsou čisté, ale drahá alcoma ne
Jinak parametry jsou suprové ohledně rychlosti či kvality signálu...

[Dalibor Toman]

1) co je za switche pred a za trasou? neni na jejich portech k Alcomam nejaka chybovost? Nektera MPcka pripojena k MT potrebuji prepnout do Slave modu
2) pisu to uz po ste - problem s (mikro)bursty. Zapnout TX flow control na Alcome a RX flow control na prislusnem portu switche (a pripadne donuti switch pouzivat vice bufferu)

[okoun]

1) žádné switche neexistují, je zapojeno do routerů Mikrotik z jedné strany RB3011 a zdruhé strany X86 Mikrotik karty, všechny strany už jsem měnil ale bez výsledku. Chybovost na ethernetu je na nule na Rx i TX
2) Flow control nemám zapnutý pač ani nevím jeslti na těch RB bude fungovat...

[Dalibor Toman]

1) žádné switche neexistují, je zapojeno do routerů Mikrotik z jedné strany RB3011 a zdruhé strany X86 Mikrotik karty, všechny strany už jsem měnil ale bez výsledku. Chybovost na ethernetu je na nule na Rx i TX
2) Flow control nemám zapnutý pač ani nevím jeslti na těch RB bude fungovat...

http://wiki.mikrotik.com/wiki/Manual:Interface/Ethernet :

rx-flow-control (yes | no | auto; Default: ) When set to on, port will process received pause frames and suspend transmission if required. auto is the same as on except when auto-negotiation=yes flow control status is resolved by taking into account what other end advertises. Feature is supported on AR724x, AR9xxx, QCA9xxx CPU ports, all CCR ports and all Atheros switch chip ports.

Pokud skutecne nikde nemas RX chyby na ethernetu (je dobre vedet, ze v danem boardu a dane verzi ROSu to ma sanci zobrazit nenulove hodnoty. RB3011 by chyby zobrazovat mela), pak jde zrejme o problem s buffery. Cili zapnout flow control a koukat, co to udela. Pripadne na tech MT zvetsit fronty k eth. Na Alcome by melo byt v ASD videt (po zapnuti TX flow), ze odesila Pause ramce - coz je indikace toho, ze opravdu je chvilema zahlcena

Jinak MT box pred Alcomou snad nikde nemame. Vzdy az za ni, takze pripadne problemy s dropy resim na switchi pred trasou.

[GRFS]

Pro ty, co pouzivaji ping jako modlu, nejprve odkaz na RFC792, kde je popis ICMP echo reply = ping. https://tools.ietf.org/html/rfc792

Cituji:

Kód: Vybrat vše

There are still no guarantees that a datagram will be delivered or a control message will be returned.  Some datagrams may still be undelivered without any report of their loss.

V prekladu: Neni tam garance doruceni datagramu, nebo navratu kontrolni zpravy. Nektere datagramy nemusi byt dorucene bez jakekoliv zpravy o jejich ztrate.

Alcoma ma defualt flow on, takze pokud je to zapnute i na protistrane, automaticky FC funguje. Vetsinou je spis problem, ze to prave linkovy partner zapnute nema. Kazdopadne v ethernet statusu by mel byt videt jak stav vyjednani flow control (on/off), tak citace out/in FC packetu. Ale to az od konkretni verze FW, starsi to neumely zobrazit.

Podle toho se pozna, kdo nestiha. Pokud radio posila out FC packety, znamena to, ze nestiha. Pokud dostava in, nestiha jeho protejsek. Pokud jsou tam nuly, neni problem.

Alcoma_flow.jpg (65.21 KiB) Zobrazeno 5811 x

Jinak se to samozrejme da resit snizenim pomeru linkove rychlosti LAN portu a skutecne kapacity radia. Pokud jsou to rychlosti pod 100Mb, nema smysl linkovat na gigu.

Nakonec je treba jeste rozlisovat firmware pod a nad 4.8, nebot tam byla udelana zmena kvuli stabilite, ktera muze zpusobit, ze od 4.8 vyse CPU v radiu dava odbaveni ICMP echo reply nizsi prioritu, nez do verze 4.8. Ale spise nez ztrata, je realna vetsi delta v odezve(latenci).

[okoun]

Pro ty, co pouzivaji ping jako modlu, nejprve odkaz na RFC792, kde je popis ICMP echo reply = ping. https://tools.ietf.org/html/rfc792

Cituji:

Kód: Vybrat vše

There are still no guarantees that a datagram will be delivered or a control message will be returned.  Some datagrams may still be undelivered without any report of their loss.

V prekladu: Neni tam garance doruceni datagramu, nebo navratu kontrolni zpravy. Nektere datagramy nemusi byt dorucene bez jakekoliv zpravy o jejich ztrate.

Alcoma ma defualt flow on, takze pokud je to zapnute i na protistrane, automaticky FC funguje. Vetsinou je spis problem, ze to prave linkovy partner zapnute nema. Kazdopadne v ethernet statusu by mel byt videt jak stav vyjednani flow control (on/off), tak citace out/in FC packetu. Ale to az od konkretni verze FW, starsi to neumely zobrazit.

Podle toho se pozna, kdo nestiha. Pokud radio posila out FC packety, znamena to, ze nestiha. Pokud dostava in, nestiha jeho protejsek. Pokud jsou tam nuly, neni problem.
Alcoma_flow.jpg
Jinak se to samozrejme da resit snizenim pomeru linkove rychlosti LAN portu a skutecne kapacity radia. Pokud jsou to rychlosti pod 100Mb, nema smysl linkovat na gigu.

Nakonec je treba jeste rozlisovat firmware pod a nad 4.8, nebot tam byla udelana zmena kvuli stabilite, ktera muze zpusobit, ze od 4.8 vyse CPU v radiu dava odbaveni ICMP echo reply nizsi prioritu, nez do verze 4.8. Ale spise nez ztrata, je realna vetsi delta v odezve(latenci).

Nu vůbec tam nemám tu kolonku pro počítadlo pause, tak jak to zjistit? Mám mp360

[GRFS]

Jedno jaka MP to je. Je treba upgrade firmware, jinak to pauzy ve statusu neukazuje.

[okoun]

jo ale update firmwaru je prý dost o ústa pokud nestojím přímo u té alcomy že

[disk]

Upgrade pres x routru bez problemu, ale nikdy ne pres vzduch toho daneho spoje a nemel jsem zadny prolem.

[GRFS]

Jde to celkem v pohode, pokud se dodrzi nekolik zasad. Jak pres lokalni port, tak ze sítě, nebo pres radio do jednotky na druhe strane. Je treba vedet, ze Alcoma pouziva pouze jednu EEPROM, takze upgrade probiha tak, ze se automaticky CPU prenastavi do boot mode, nasledne se smaze stary obsah a pak se tam teprve programuje novy. Pote zpet autorestart a prepnuti do normalniho modu. Pokud dojde ke ztrate komunikace behem zapisu, lze zapis opakovat, ale jen pokud jednotka neztrati napajeni. Pak uz jedine odvezt na stul k vyrobci.

Jinak samozrejme s aktualizaci firmware je treba i aktualizace ASD klienta ve smyslu podpory zobrazeni novych funkci. Stary ASD klient na Alcome s novym firmware bude porad zobrazovat jen to, co umi ta stara verze klienta.

[okoun]

Jde to celkem v pohode, pokud se dodrzi nekolik zasad. Jak pres lokalni port, tak ze sítě, nebo pres radio do jednotky na druhe strane. Je treba vedet, ze Alcoma pouziva pouze jednu EEPROM, takze upgrade probiha tak, ze se automaticky CPU prenastavi do boot mode, nasledne se smaze stary obsah a pak se tam teprve programuje novy. Pote zpet autorestart a prepnuti do normalniho modu. Pokud dojde ke ztrate komunikace behem zapisu, lze zapis opakovat, ale jen pokud jednotka neztrati napajeni. Pak uz jedine odvezt na stul k vyrobci.

Jinak samozrejme s aktualizaci firmware je treba i aktualizace ASD klienta ve smyslu podpory zobrazeni novych funkci. Stary ASD klient na Alcome s novym firmware bude porad zobrazovat jen to, co umi ta stara verze klienta.

v čem je prosím ten fw 4.8 stabilnější? mám 4.2 dneska jsem tam ještě dal výkonější router ale PL tam je stále a už mě to tedy parádně točí, už pči 120Mb se tam vyskytne, je zajímavé že druhá alcoma to nedělá ale ta má podstatně starší FW....

[GRFS]

To nema nic spolecneho s tvym problemem. Uz ti ukazuje Ethernet status ty pauzy ?

[Dalibor Toman]

v čem je prosím ten fw 4.8 stabilnější? mám 4.2 dneska jsem tam ještě dal výkonější router ale PL tam je stále a už mě to tedy parádně točí, už pči 120Mb se tam vyskytne, je zajímavé že druhá alcoma to nedělá ale ta má podstatně starší FW....

kdyz te to toci tak proc to nezacnes resit?

[okoun]

v čem je prosím ten fw 4.8 stabilnější? mám 4.2 dneska jsem tam ještě dal výkonější router ale PL tam je stále a už mě to tedy parádně točí, už pči 120Mb se tam vyskytne, je zajímavé že druhá alcoma to nedělá ale ta má podstatně starší FW....

kdyz te to toci tak proc to nezacnes resit?

děláš si legraci asi ne?
to řeším furt aktivované flow control nepomohlo, výměna za silnější router také nepomohla, teď jsem ještě změnil frontu na ifacu z only HW na pfifo 100 tak uvidíme...

[Dalibor Toman]

děláš si legraci asi ne?
to řeším furt aktivované flow control nepomohlo, výměna za silnější router také nepomohla, teď jsem ještě změnil frontu na ifacu z only HW na pfifo 100 tak uvidíme...

100 packetu hahaha. To nema smysl ani nastavovat. Prijde ti 100 50ti bytovych packetu a fronta jako by nebyla.

Zkusil bych
1) proverit, ze flowcontrol neco dela - tj chodi rxPausy od Alcomy. Novejsi verse ROSu zobrazuje na interfacu pocitadlo rxPause ramcu - pokud roste, pak Alcoma posila rxPause requesty. Pokud neroste tak bud neni dost burtu v provozu nebo Alcoma nic neposila. Obcas jdou chytit Pause ramci i snifferem (https://ask.wireshark.org/questions/9718/pause-frame)
2) nastavil bych na MT shaper na hodnoty o neco nizsi nez je max prenosovka te Alcomy a pak bych zkusil co se deje se ztratovosti. Pokud bude stratovost pokracovat a zaroven bude shaper hlasit, ze zahazuje packety cca ve stejnem poctu pak je to na dobre ceste. Zvysenim delky fronty na interfacu by se to melo spravit (ale 100 packetu fakt IMHO stacit nebude - pokud teda nebezi radio na modulaci ala 32mbps). Obvykle na switchich nastavuji (pokud to jde) 2MB frontu. Razantni ubytek discardu nastava od velikosti fronty v par stovkach MB (tj ne fronta na pocet packetu ale na celkovou velikost).