mám také jen na Rx ale asi to je tím že ta druhá strana neumí počítat?
nastává otázka čím to je že ty dropy v znikají...
Tx/Rx Errors a Tx/Rx Drops
RX drops by mělo znamenat, že síťovka do svého hardwarového bafru přijala paket OK, ale nestihla ho dostat do paměti počítače pro přetečení toho kruhového bafru, takže nějaký krátký burst, kdy to DMA nestihlo dostat ven ze síťovky do RAM.
TX drops to počítat umí, je to podobné, že se sestavil komplet paket na odeslání a nestihl se odeslat síťovkou ven na dráty (takže ne, že to jsou chyby oznámené od protitrany na jejim přijmu). Uvidíš je třeba na VLANě, sestavují se pakety na VLAN rozhranní, pak se cpou do síťovky, pokud síťovce odpadne link, tak ty pakety se zahodí a naskočí jako TX drops. Podobně i na dalších místech.
no nastává otázka jeslti to nemá dopad na kvalitu konektivity, ale nikdo si nestěžuje, nicméně lidi na vesnici si pomalu nestěžují na nic, právě proto zde stále všude kvetou 2,4GHz a činské krabičky :)
no nastává otázka jeslti to nemá dopad na kvalitu konektivity, ale nikdo si nestěžuje, nicméně lidi na vesnici si pomalu nestěžují na nic, právě proto zde stále všude kvetou 2,4GHz a činské krabičky :)
tak si spocitej kolik % packetu se to vlastne ztraci. Mne vyslo, ze cca 3 desetitisiciny promile. Takze to je hluboko pod urovni pozorovatelneho vlivu. Subjektivne to poznas IMHO az od urovne jednotek procent ...
Tyhle dropy muzou nastavat casto i v pripadech, kdy na zarizeni jsou spousteny nejake na CPU/OS narocne ulohy (na linuxu trebe reload iptables, tc). Je dobre mit tyhle veci vsechny v grafech (ted hura vsichni psat na support MT, ze to nejde vycitat pomoci SNMP at je tim neotravuju stale jen ja :-) ), aby se dalo urcit kdy k chybam dochazi - pripadne, kdy to zacalo atd.
no tak mi vyšlo podobné procento, tak to tedy asi nebud enic vážného :)
o 3 roky později
Jak je to s TX drops na VLAN?
Na GW která dělá shaping se nám na každé VLAN se objevují TX dropy. Co to může způsobovat, na co se zaměřit?
GW x86 i5, síťovka SGP-i2, proti CISCO SG300. Skrz jedou VLANy do dalších zařízení po 1Gb linkách na APčka. Něco optikou, něco 80G atd. Na konci zase switch a na něm odtagováno a jede to buď 100Mb nebo 1Gb ethernetem dál.
pokud ty shapery sedi v tech VLANkach, pak by to mohly byt packety zahozene shaperem (plna fronta). Staci porovnat statistiku VLANu se statistikou shaperu. POkud je to treba resit, melo by pomoci prodlouzit fronty
Otázkou je, jestli má smysl ty mizivá promile dropů řešit ...
o 21 dní později
Jak je to s TX drops na VLAN?Na GW která dělá shaping se nám na každé VLAN se objevují TX dropy. Co to může způsobovat, na co se zaměřit?
GW x86 i5, síťovka SGP-i2, proti CISCO SG300. Skrz jedou VLANy do dalších zařízení po 1Gb linkách na APčka. Něco optikou, něco 80G atd. Na konci zase switch a na něm odtagováno a jede to buď 100Mb nebo 1Gb ethernetem dál.
mám velmi podobné řešení a drop na vlaně ani jeden, zvláštní...
o 8 let později
- Upraveno
Jedná se už o zastaralou diskuzi, ale přesto ji otevřu. Psal jsem si o tom s hapi, dohledal i na angl. fórech informace, že je to dost častý jev, ale zeptám se:
Jak jste na tom u x86 s RX errory u verze x86? Když jsem jel na v6, tak jsem měl 100vky rx dropu s uptime 10tek dnů, takže jakoby tam byla nula. Jenom obyčejným upgradem na v7 a je jedno jak je to verze, zda 17.12.1 nebo vyšší, je počet dropů už řádově v setinách procent. ANo, vím že se tu psalo, že si toho nemám všímat, ale i tak se ptám. Pozorujete to stejné i u Vás? Já mám tyto rx dropy mezi 10Gbit intel sitovkou v x86 a 10Gbit portem v Edge-core ECS4120-28T. Změna flow control, auto negotiation na to nemá vliv. Měněna i fronta u QT, taky nic. Server je uzemněny, včetně jako switch edge.
Má smysl to řešit a nebo se raději vrátit na v6, kde to dá se říct nedělá. Má smysl mít v7 na x86, je tam nějaký přínos na řízení provozu? Osobně zatím nic nepozoruji, vytížení apod. stejné.
Pro upřesnění, jde u upload směr, tedy to co jde od zákazníků přes GW ven,. Download smět (TX error) je nulový. Přitom upload je oproti downloadu využitý v poměru 1:20.
Díky za odpověď.
pepulis Rovnako, u nas je to x86 s ROS v7.14.3 Sietovky QSFP+ (tusim melanox) + CPU 8 core Xeon. CPU chodi 15-20% pri celkovom trafiku cca 20-24 Gbit. - RX drop 3750, RX error 2 900 000 - za cas uptime 97 days.
Vyrazne pomohli zmeny nastaveni vo fronte QT. Okrem toho sme nic nemenili. Stratovost do internetu ani u klientov nepozorujeme, ani monitoring ho nevidi.
Tento problem aj s realnou stratovostou asi 0,5% sme mali na ROS v6 a starsim x86 HW kde boli len 10Gbit sietovky, tam sme to uz ale mali v spicke upchate, takze to spravi vselico + CPU bol starsi (rv 2018 tusim) Xeon 4 core ktory chodil ókolo 55% a uz to je samo o sebe problem, aj to nam robilo stratu. Samozrejme upgrade z v6 na v7 sa nikto neodvazil spravit, takze sa to vyriesili vsetko az z novym HW.
Po viacerych zistovanich od ludi ktori prevadzkuju siete z traficom 10G+, ze je to viac menej normalne a pokial nie je realna stratovost tak neriesit. Okrem toho je absolutne minimum ludi, ktore ma know how realne na brane ktora ma ine nez 10G sietovky. 10G je zvladnuta a prebadana vec, 40 ci 100G nie a clovek laboruje a nikto o tom nic nevie, s mikrotikom to bolo na dlho aj kvoli driverom.
gemb Děkuju za odpověď. Zkoušel jsem tedy vypnout QT na upload i download a nic, respektive rx errory skáčou pořád, za jeden den jich mám cca 180 000, jde o 0.01308% k počtu přenesených paketů. CPU 8 core - teď ráno se fláká a jede tak 2-3%, večer v průměru 10-15%. Nevím jestli má smysl vyměnit ten switch Edge-core ECS4120-28T nebo sfp modul.
vdr Nie
pepulis Switch by som urcite nemenil a zmena SFP modulu je loteria. Zatial sme mali len 1 par modulov ktore chybovali (z cdr.pl - opton wdm 10G) a je mala sanca, ze to pomoze. U nas to mame do switchu Huawei CloudEngine S6730-S24X6Q. Do neho sme mali aj 10G prepoje s x86, teraz 40G. U nas mame pouzite QSFP+ DAC kable o dlzke 2m. Taktiez mame aj prepoj s QSFP+ AOC kablom na 15m. Nemame problem ani s jednym ale priamo QSFP+ opticke moduly vlastne neprevadzkujeme...
Dvě x86ky s i3-8th a síťovky X520-DA2, zapojeno pomocí DAC kabelů do DCN switche. Errory ne, TX dropy na VLANách ano.
- Upraveno
error je hw chyba. Dojde špatný paket kterému nesouhlasí CCR = error.
drop je sw chyba/overflow. Příchozí paket není kam uložit, plný buffer v ethernet chipu = drop.
Drop občas bývá u RB i na ostatní věci třeba na multicast nebo pakety o flow controlu. Asi nejsou brány jako provoz pro router samotný a počítají se tam.
je třeba také vzít v potaz že x86 na v6 ani jedno většinou neukazuje ale v7 už ano.
TX dropy většinou řeší zvětšení velikosti fronty v queue na interface. RX dropy ne.
Pomáhá ručně přiřadit IRQ na jádra pěkně postupně a vypnout RPS pokud má ethernet multi IRQ.
Já třeba mám na GW s X710 průměrně za den 0.1 pps errorů a 0.02 pps dropů. Ale jenom na vstupním iface, Na iface do sítě to je 0.025 pps a 0.037 pps. A mám tam jednu vlanu na každém iface.
Asi bych mohl zkusit vyměnit moduly.
hapi Jaké moduly prosím nyní používáš? Já tam mám nyní tohle https://www.alternetivo.cz/sfp-transceiver-10gbase-lr-lw-multirate-sm-10km-1310nm-lc-dup-dmi-intel-komp-_d36471.html?whisperword=SFP-PLUS-LR10-INT%20(E10GSFPLR)
Díky.
Jen taková moje osobní zkušenost k podobné věci s 10G moduly/DAC . Mám v racku propoje na 10G, ať už DAC nebo přímo optické moduly a často se mi po nějaké době stalo, že se začala objevovat ztrátovost. Nikdo nic nereportoval, na první pohled nikde nic nezlobilo, jen na grafu se začala objevovat marginální ztrátovost (2x za den), která byla docela ustálená (měsíce) a pak se z ničeho nic zvedla výrazně a zase klesla. Ztrátovost se zdála minimální, ale zajímavé bylo, že se objevovala na všech grafech které přes ten router fungovaly a to v různých časech. Když si pak "promítnete" ty grafy přes sebe tak už to tak marginální nebylo.
Měl jsem DAC od mikrotiku, různé OEM moduly na 10G. Výměna switche/síťovky/konfigurace front nepomáhala. Co pomohlo byla výměna DAC/optiky za nový. Náhle žádný problém nebyl, bohužel po půl roce se začal problém zase plíživě objevovat. Nakonec jsem skončil u obyč DAC z discompu pod jejich značkou Maxlink a k mému překvapení fungují už dva roky. Věřím tomu že kdybych koupil "pořádnou" značku hned na začátku, tak bych problém neměl. Nyní na uptimu 150 dní mám na celém routeru 3x rx-error, cca 1000 rx-drop a na Tx 0error/drop
Takže za mě zkusit vyměnit propoj je to nejlehčí co se dá zkusit.
pgb my pouzivame 90% maxlink moduly aj maxlink dac kable - okrem jedineho modulu nebol problem...a ten jediny proste vymrzol a nesiel...stacilo vypat/zapat interface a rozbehol sa. Pri 40G to ale nie je take jednoduche, tam sme narazili na problemy s kompatibilitou, niektore DAC nam ani nefungovali, nebolo mozne donutit ani switch ani x86 aby to linklo...nakoniec sme brali dac aj aoc z FS.com, to islo nasupu a drahe to nebolo.
- Upraveno
gemb Jsem rád že ty moduly z fska chodí. Já jsem dospěl k názoru že 40G je slepá cesta. Jedná se o můj osobní názor. Je to z důvodů že 40G je 4x10G, kdyžto 100G je 4x25G. Navíc existuje většinou kompatibilita u sfp28 až do 1G sfp. Možná s tím leckdo nebude souhlasit, hádat se nehodlám. Nicméně i na lupě vyšel článek od quantcom k zamyšlení ... "Je pětadvacítka novým desetigigabitem?"
