Queue Tree a nastaveni type Queue

hapi

To je to o čem jsem psal. Plný buffer dropuje a rychlost je nižší protože jsou ztráty.

A určitě má vliv nastavení fronty i pro QT/SQ. Je to to samé. Vem si třeba jak velký musí být TCP window size při 100Mbit. To by se nějak mělo vejít do queue. A dneska těch spojení je hodně a když se ti to ztrácí, tcp snižuje window size a klesá rychlost. Vytáhnout vysokou rychlost na jedno spojení není žádná legrace a ty buffery tomu pomůžou.

Ano, zaznamenal.

pepulis

U RB je casto a nebo mozna u vsech typu ethernet interface nastaveny typ queue na only-hardware-queue, ktery je none. Doporucujes ho tedy prenastavit na jiny = napr. ethernet-default s hodnotou queue site u pfifo na vyssi hodnotu - napr. 1000 a nebo je to u rb3011 (vse 1Gbit) jedno a zmena z only-hardware-queue na ethernet-default nebude mit zadny znatelny vliv?

ekrajnak

hapi nechapem, preco tato odpoved po pomaly dvoch rokoch, ale vdaka za nu!!!

Uz vo vedlajsom vlakne som pisal ze vsetky RB3011 a RB4011 u nas na sieti maju vysoky discard rate na portoch a nastavenie pfifo front, ako teraz skusam, robi zazraky - samozrejme s rozumnou velkostou fronty, aby nedochadzalo k dicardom ale zaroven ani velmi velkemu oneskorenie, lebo aj to vplyva na TCP priepustnost a samozrejme pre latency critical sluzby je velky jitter nepripustny.

Ale ak ma prepocty neklamu, fronta 500 paketov s 1500 bajtami pri 1Gbps porte sposobi oneskorenie max. 5ms. To je zanedbatelna hodnota.

Ja mam problem na RB4011 naplnit 1Gbps port na 400M bez discardov. Ci je horsie, saturacia napr. 100Mbps portu Ether7 sposobuje brutalne discardy na 1Gbps porte Ether9. Viď. príklad:

Ether7 Traffic

Ether9 Discards

hapi

ekrajnak nechapem, preco tato odpoved po pomaly dvoch rokoch, ale vdaka za nu!!!

Protože to fórum mi to nabídlo jako nepřečtenou zprávu tak jsem reagoval a nečetl datum 🤔

hapi

ekrajnak saturacia napr. 100Mbps portu Ether7 sposobuje brutalne discardy na 1Gbps porte Ether9. Viď. príklad:

Jo, tohle není nenormální. Máš to ve switch režimu nebo ne?

hapi

Já to doporučuju. Ať se zkusí vyjádřit i jiní.

U RB3011 je to doporučený samotným mikrotikem kvůli flapovani portu které to prý zmírňuje.

ekrajnak

hapi oba porty sú routované. Ether7 je access port (bez VLAN), Ether9 je trunk. RB4011, ROS 6.48.5. Interface queue sú v defaulte (ethernet - only-hardware-queue, vlan - no-queue)

EDIT: NEPLATÍ: Inak in/out discard countery sa pre VLANy ani nenachádzajú vo Winboxe, ale sú dostupné cez SNMP.

pgb

hapi na tuhle chybu jsem už několikrát upozorňoval a mk o ní ví a nic s tím nedělá, je tam problém s interním flowcontrol mezi switch chipem a cpu (opravdu si to nevymýšlím a mk to uznal)

ekrajnak

pgb ten problem, ktory spominas je u RB4011? To by znamenalo, ze nastavenie interface queue nepomoze, tak? Budem to testovat ale az v noci, nie ze sa mi zadrhne RB4011 po prepnuti front a pridem o pol giga trafficu na sieti 😃

U jednej RB3011 som od 17:30 nastavil na Ether5 pfifo frontu, 500 paketov. 100Mbps port s koncovym 5G sektorom. Od vtedy uplne ciste. Inak v takomto case by tam bolo okolo 5-20 discards/s.

Discard rate
Bits sent

pgb

ekrajnak jo je i u 4011 (je to skoro všude kde je switch chip) pomůže jediné, zajistit aby nedošlo k saturaci 100M portu s rezervou. Takže pověsit na interface třeba SQ https://youtu.be/n_OAcLXhd_M

Edit: ----smazáno--- napsal jsem blbost

jenya

ekrajnak Jsou ty discards nekde na citacich v mikrotiku videt? Tuto polozku tam nemohu najit. Je tam Tx drop a Rx drop, je to ono?

hapi

je to u všech RB s chip switchem s potenciálem ject na gigu. Proto se obávám tý CCR2116 kde to bude to samí v bledě modrém stejně jako jeho oba předchůdci CCR2004 a RB4011/3011. Je to jenom otázka velikosti datového provozu. Zatím jsme na to u RB4011 nenarazili (uplink přes SFP+ cca 1-1.2Gbit) ale hned za tím je RB3011 a ten už to teda při 300Mbit cítí a blbne.

Ono se to rozbije i při příchozím provozu? člověk by řekl že do chip switche to přijde nerušeně na 100Mbit a dál to jede po rychlý sběrnici do cpu a pohoda. Já mám spíš opačný problém a to je dostat to z toho ven obzvlášť když zařízení hned za ním občas pošle FC.

pgb

hapi Ono se to rozbije i při příchozím provozu? člověk by řekl že do chip switche to přijde nerušeně na 100Mbit a dál to jede po rychlý sběrnici do cpu a pohoda. Já mám spíš opačný problém a to je dostat to z toho ven obzvlášť když zařízení hned za ním občas pošle FC.

omlouvám se, pravdu máš, nějak mi nedošlo že píšu blbost ...

ekrajnak

jenya no sam som z toho zmateny:
existuju 4 pocitadla vo Winboxe:
Rx drop v zalozke Rx stats
Tx drop v zalozke Tx stats
Tx/Rx drops v zalozke Traffic

Pri ethernet interface su vo winboxe dostupne vsetky styri, avsak pocitadla v zalozke Traffic su stale 0. Realne hodnoty su v zalozkach Rx stats / Tx stats.

Pri vlan interface zalozky Rx stats / Rx stats neexistuju a realne hodnoty ukazuju pocitadla Tx/Rx drops v zalozke Traffic.

Cez zabbix vycitavam OIDy
in-discard 1.3.6.1.2.1.2.2.1.13.{#SNMPINDEX}
out-discard 1.3.6.1.2.1.2.2.1.19.{#SNMPINDEX}

a viem ze urcite to vycitava korektne discardy pre VLAN interface. Ale zacinam rozmyslat ci pre ethernet interface nie su potrebne ine OIDy....

ekrajnak

No, takže potvrdené: pre vyčítanie Rx/Tx drops pre Ethernet interface (nie vlan subinterface) treba použiť vendor specific OIDy:
mtxrInterfaceStatsRxDrop 1.3.6.1.4.1.14988.1.1.14.1.1.55
mtxrInterfaceStatsTxDrop 1.3.6.1.4.1.14988.1.1.14.1.1.85

Pridávam príklad: RB4011, ROS 6.48.5. Port ether9, nie je v bridgy. Podľa winboxu, v záložke Rx stats: Rx drops cez 135k. Podľa zabbixu (OID 1.3.6.1.2.1.2.2.1.13) nič.

winbox screenshot

zabbix graph

Další stránka »