Porovnání automatické balancování SFQ/fq_codel/tc-cake

pgb · 2020-03-18T18:21:51+00:00

Tohle je přesně důvod, proč je dobré dělat zákazníkům balancing domácích přípojek a používat moderní AMQ. Popis testu: sledujte rychlost spodního mikrotiku...

pgb

hapi V tom je ten vtip, ať už u pcq nebo u cake můžeš otočit src a dst ip. Takže do zákazníkovy download třídy vložíš PCQ/cake frontu, které jako balanční atribut zvolíš SRC IP/port těch dat. Takže dochází k tomu, že příchozí provoz s DST IP klienta se vnitřně balancuje podle SRC IP zdrojů z netu. Celé to analogicky pro upload od zákazníka. Jasně že to není dokonalé, potencionálních stavů je mnoho, ale ve výsledku to funguje moc hezky.

felix

Používáte někdo fq_codel? Nějaké zkušenosti s parametry? Zatím zkouším zvyšovat limit a flows. Má smysl upřednostnit malé packety změnou quantumu? Děkuji za zkušenosti :-)

pgb

felix na linuxu ano, na rosu ne. V rámci obecných rad se bývá uvedeno quantum 300 < 100Mbps třídu. Limit nemá smysl zvyšovat, spíš snižovat ... Flow je default 1024, to mi přijde až až na jednu třídu (pokud jednou třídou rozumím koncového zákazníka)

felix

pgb A je parametr flows urcite jen na jednu tridu? Neni to globalne pro alokovani pameti pri inicializaci? Pri hodnote 1024 mi to pri zatezi droplo cely traffic na polovinu a pomohlo navyseni flows. Zatim monitoruji aktualni pocet behem dne...

pgb

felix tak záleží na kterou třídu ten fqcodel věsíš. Já mám htb strom a v něm queuing discipliny nastavuji až na úplně koncové třídě. Žádný propad tam není protože každá koncová třída má pověšenou svoji queuing disciplinu s 1024 flow.

felix

pgb Davam to na koncovou tridu htb pro jedno ip in a out. Celkem asi 2x1200 htb trid. Jestli je to 1024 flows jen pro tu tridu, tak nechapu, proc to navyseni pomohlo. Kdyz dam tc -d class show dev eth0/1 | grep codel , pohybuje se denne od 1000 do 15000 fq_codel class, coz jako cca 5ti nasobek aktualnich flows na portu sedi. Jinak s presnosti a odezvou (quantum 300 limit 10240) jsem spokojenej. Az dam novej kernel, zkusim jeste cake, vypada slibne.

felix

pgb Tak nakonec je podle doporuceni quantum 300 limti 1000 na koncovou htb tridu nejlepsi volbou.

ekrajnak

Skúšali ste už niekto zavesiť Cake ako interface queue na wlan interface? Ideálne s cake-flowmode: dual-dsthost pre spravodlivé rozdelenie pásma.

soban

ekrajnak Zkoušel ovšem pouze doma a tam to nemá význam, aspoň jsem nepozoroval rozdíl.

Ale zkouším cake pouze na odchozím interfacu do internetu k ISP na DSL a Optice a tam to zdá se funguje OK.

/queue/tree> print
Flags: X - disabled, I - invalid 
 0   name="QoS_Optika" parent=pppoe-optika packet-mark=no-mark limit-at=0 queue=cake-500M priority=8 max-limit=0 burst-limit=0 burst-threshold=0 
     burst-time=0s bucket-size=0.1 

 1   name="QoS_he.net" parent=he.net packet-mark=no-mark limit-at=0 queue=cake-he.net priority=8 max-limit=0 burst-limit=0 burst-threshold=0 
     burst-time=0s bucket-size=0.1

/queue/tree/print
Flags: X - disabled, I - invalid 
 0   name="QoS_LTE" parent=lte1 packet-mark=no-mark limit-at=0 queue=cake-lte-5M priority=8 max-limit=0 burst-limit=0 burst-threshold=0 
     burst-time=0s bucket-size=0.1 

 1   name="QoS_VDSL" parent=T-MOBILE VDSL packet-mark=no-mark limit-at=0 queue=cake-vdsl-10M priority=8 max-limit=0 burst-limit=0 
     burst-threshold=0 burst-time=0s bucket-size=0.1

Přímo v nastavení cake mám zadanou natvrdo rychlost.

ekrajnak

Jop. Prihodím aj ja skúsenosti zo včerajšieho labovania Cake ako interface queue nad wlan interface.

Vo všeobecnosti Cake funguje nádherne, ak pozná širku pásma (a teda je nastavený cake-bandwidth). Funkcia cake-autorate-ingress sa správa veľmi zle, orezuje linku na veľmi malé hodnoty, sice ich postupne dvíha, ale aj tak je latencia vysoká.

Pri použití nad wlan interface je rozdiel medzi SFQ (default v ROS 6 aj 7.1) a Cake takmer žiadny. A v podstate potvrdzuje to aj samotný autor Cake qdisc.

Best qdisc still had 100ms+ of bloat on WiFi.

Odporúčam pozrieť prednášku https://legacy.netdevconf.info/2.2/session.html?jorgensen-wifistack-talk
Zvýšenú latenciu a unfairness pri rozdeľovaní airtime spôsobujú drivery, takže to qdisc neporieši.

Do Linux Kernelu pribudli úpravy mac80211 a ath9k/ath10k ovládačov, ktoré implementujú FQ a Cake na najnižšej úrovni. Dané vylepšia už sú súčasťou Linux kernelu (https://github.com/torvalds/linux/commits?author=tohojo), niektoré od roku 2016, niečo pribudlo v 2019 až 2021. Otázne je, či Mikrotik v ROS7 implementoval tieto úpravy wifi 802.11 protokolu - podľa meraní sa mi to nezdá, ale ak áno, bude to pre zákazníkov s hAP výrazné zlepšenie a určite sa oplatí upgradovať.

Hore uvedené platí pre Mikrotik wlan s 802.11 protokolom. NV2 je na tom podstatne lepšie a rieši fairness/bufferbloat problémy už dávno a po svojom.

felix

Používáte nějaké prametry pro cake, když je zavěšený na htb? Měl jsem fq_codel quantum 300 limit 1000 a zkouším teď cake, jestli to při saturaci, když jedeme přes zálohu, bude lepší. Dík!

hapi

z vlastního testování jsem bohužel rozdíl mezi např. pcq, codel a cake nenašel. Tedy záleží na nastavení ale více méně nic. Mnohem lepší je nastavit htb tak aby k saturaci nedocházelo a nechat pak pracovat frontu v htb.

« Předchozí stránka