RB2011UiAS - packetloss na ethernetech

[czatlantis]

6.30 - dělá

[okoun]

bude to někdo hlásit na suport at je nás více a nebo na to kašlete?

[honzam]

Určitě to chce řešit se supportem. Klidně bych to nahlásil ale nemám ISP admina a na smookepingu žádnou ztrátovost nevidím (s aktuálním nastavením)

[okoun]

já tam určitě napíšu ale potřebuji nějaký jasný test který si udělají i oni u sebe.

[czatlantis]

Nějakej jednoduchej ping test na windowsy nemáte? Ten smokeping vypadá nějak moc složitě na konfiguraci (resp se mi s tím nechce drbat). Ideálně něco jako iperf, kde na jedné straně spustím jedním příkazem server, na druhé klienta a nechám to chvilu jet a ono to bude ukazovat, kolik se ztratilo.

[okoun]

zkoušeli jste už tu verzi 6.32rc6? něco tam opravovali ohledně ethernetů na RBčkách, které mají switch chip...

[lukic]

Tak 6.33.rc35 to robi furt.. downgrade na 6.7. pomohol a linka ide bez straty minimalne na ping (ICMP)..

[tron]

Dela vam taky u tohohle kramu to, kdyz ve winboxu koukam na datovy tok na ethernetech, tak to vzdycky po par sekundach jakoby spadne?
Par sekund je tam normalni provoz a pak se to na sekundu vynuluje. Data normalne prochazi, ale na citacich jsou vsude 0....
Tam kde mam verzi 6.10 to nedela, na 6.23 a 6.30.1 jo.

Bohužel dělá taky...

[okoun]

ano, cca už přes 3 týdny řeším problém se suportem, řešíme to na CRS což je obdoba 2011 a i na RB951 tam je to o poznání menší, ale je. Zatím za ty 3 týdny co tam mají přístup a různě nastavují queue na ethernetech ale zatím prdlačka, už mě to celkem teda točí a je tedy také

[OK1COM]

Tak 6.33.rc35 to robi furt.. downgrade na 6.7. pomohol a linka ide bez straty minimalne na ping (ICMP)..

Narazil jsem na stejny problem s PL na RB2011. Vzkousel jsem vsechno mozne, ale pomohl az downgrade na 6.7. Dekuji!

[okoun]

tak vážení support mi dnes napsal, že ten problém tam je, že to přiznávají, ale že vlastně to není takový problém, že je to opravdu velmi malý packetloss a třeba na RB951 je totálně malý.
jinak prý se to vyskytuje když na chvilku prudce stoupne datový tok, prostě velkým skokem třeba na 1-5sec.

nevim no, ale asi by je měl začat bombardovat s tímto problémem i někdo jiný, já tedy zatím nepřestávám bojovat dále, toto se prostě v lepších sítích dít nemá

[jarda.jezek]

... a já měl zato, že jde jen o nesynchronizovanou změnu proměnné s cykly jejího čtení...

[Dalibor Toman]

tak vážení support mi dnes napsal, že ten problém tam je, že to přiznávají, ale že vlastně to není takový problém, že je to opravdu velmi malý packetloss a třeba na RB951 je totálně malý.
jinak prý se to vyskytuje když na chvilku prudce stoupne datový tok, prostě velkým skokem třeba na 1-5sec.

nevim no, ale asi by je měl začat bombardovat s tímto problémem i někdo jiný, já tedy zatím nepřestávám bojovat dále, toto se prostě v lepších sítích dít nemá

tady je podstatne vedet skutecnou pricinu tech ztrat. Existuji legitimni duvody pro ztratu - napriklad zaplneni bufferu, pokud nastava situace, ze soucet prichodu je vetsi nez odchod (rychlosti). Ale je daleko vice neomluvitelnych ztrat (chyby software, hardware atd). Takze za urcitych okolnosti je ztratovost omluvitelna a za jinych ne. Napsal k tomu MT nejake podrobnosti?

Btw: ten problem se projevuje jen pri pouziti switch chipu? Nejsem si nejak z historie tohohle vlakna jisty. RB2011 pouzivame v bridge CFG a tenhle problem nepozoruji. HW countery chyb nic neukazuji? (v tech ROSech kde to ma smysl sledovat - starsi 6.x je neaktualizuji)

Jinak k testu ztratovosti se mi osvedcil ping z linuxu s parametrem -A (= posilej ICMP dotazy tak rychle jak chodi odpovedi) a nastavena velikost > 1500. Pokud je nekde problem s velkou pravdepodobnosti se to projevi

[okoun]

mě to dělá jak v bridge tak v switchi, nicméně děje se to a od určité rychlosti, momentálně se na to nějak dál suport vykašlal, jdu je zase trochu kopnout a zkuste je kopat také aby se na ně víc tlačilo...

[Dalibor Toman]

mě to dělá jak v bridge tak v switchi, nicméně děje se to a od určité rychlosti, momentálně se na to nějak dál suport vykašlal, jdu je zase trochu kopnout a zkuste je kopat také aby se na ně víc tlačilo...

tak jim jeste napis, ze by bylo kvuli tomu fajn pridelat counter na Discardy, aby se dalo sledovat, kdyz box zahodi packet kvuli plne fronte na odchodu. A aby to bylo k necemu, tak by konecne mohl ROS misto 0 vracet u SNMP counteru pro chyby vracet skutecna cisla. To same u nonUnicast packetu...