Puncte:0

Parametrul „rata” HTB limitează lățimea de bandă disponibilă

drapel jp

O zi buna,

Am următoarea situație: 4 fluxuri TCP de date de la o mașină la alta. Fiecare flux are propriul său port TCP de destinație. 4 fluxuri au priorități diferite: mare, medie, scăzută, vrac. High, medium, low generează 1,67 Mbit/s, iar în vrac generează 10 Mbit/s. (iperf3 folosit pentru a genera trafic). Pachetele fiecărui flux sunt marcate cu marcajul DiffServ corespunzătoare (DSCP) și acest marcaj este utilizat pentru clasificarea traficului în qdisc-ul HTB.

Poartă: HTB qdisc ar trebui configurat astfel încât în ​​orice moment fluxul cu prioritate înaltă să obțină 1.67Mbit/s necesar, prio mediu este de asemenea garantat 1.67Mbit/s, dar cu un prior puțin mai mic, iar restul traficului ar trebui să fie garantat 50kbit/ s. Fiecare flux trebuie să poată utiliza întreaga legătură dacă este inactiv și fluxul generează mai multă lățime de bandă decât cea specificată inițial.

Generare de trafic:

Prioritate ridicată:
iperf3 -c 192.168.88.254 -p 5150 -t 62 -b 1.67M -l 128 -S 224 
Prioritate medie:
iperf3 -c 192.168.88.254 -p 5160 -t 62 -b 1,67M -l 4K -S 160 
Prioritate redusa:
iperf3 -c 192.168.88.254 -p 5170 -t 62 -b 1,67M -l 4K -S 96 
În vrac:
iperf3 -c 192.168.88.254 -p 5180 -t 62 -b 10M -l 4K -S 0 

Configurarea HTB qdisc

NI="eth2"
AC="sudo /sbin/tc class add dev"

# Ștergeți qdiscurile anterioare
sudo /sbin/tc qdisc del dev $NI root

# Adăugați HTB ca rădăcină cu clasa implicită 40 pentru trafic necategorizat
sudo /sbin/tc qdisc add dev $NI root handle 1: htb default 40
sudo /sbin/tc class add dev $NI parent 1: classid 1:1 htb rate 3.5mbit ceil 1000mbit

# flux cu prioritate mare DSCP 224 - 1110 0000 - 0xE0
$AC $NI parent 1:1 classid 1:10 htb rate 1.7mbit ceil 1000mbit prio 1
# flux cu prioritate medie 
$AC $NI parent 1:1 classid 1:20 htb rate 1.7mbit ceil 1000mbit prio 2
# flux cu prioritate redusă
$AC $NI parent 1:1 classid 1:30 htb rate 50kbit ceil 1000mbit prio 3
# flux în vrac
$AC $NI parent 1:1 classid 1:40 htb rate 50kbit ceil 1000mbit prio 4 

# Adăugați filtre pentru a clasifica pachetele pe baza marcajului dscp

# DSCP cu prioritate ridicată 224 - 1110 0000 - 0xE0
sudo /sbin/tc filter add dev $NI protocol ip parent 1: prio 1 u32 match ip tos 0xE0 0xff flowid 1:10
# DSCP cu prioritate medie 160 - 1010 0000 - 0xA0
sudo /sbin/tc filter add dev $NI protocol ip parent 1: prio 2 u32 match ip tos 0xA0 0xff flowid 1:20
# DSCP cu prioritate scăzută 96 - 1100 0000 - 0x60
sudo /sbin/tc filter add dev $NI protocol ip parent 1: prio 3 u32 match ip tos 0x60 0xff flowid 1:30
# DSCP în vrac 0 - 0000 0000 - 0x00
sudo /sbin/tc filter add dev $NI protocol ip parent 1: prio 4 u32 match ip tos 0x00 0xff flowid 1:40

Traficul este clasificat corect. Pot vedea contoare relevante în statisticile clasei tc crescând. Am verificat asta de mai multe ori.

Problemă: Această configurație alocă corect lățimea de bandă fluxurilor cu prioritate mare și medie. Prioritatea scăzută și vrac primesc, de asemenea, 50 kbit. In orice caz, Nu pot trece prin link mai mult decât valoarea specificată în rădăcină clasa 1:1 la fel de rată adică 3,5 biți.

În fiecare articol și manual despre HTB pe care l-am citit s-a afirmat, acel parametru „rata” este rata minimă garantată pentru clasă, iar „plafonul” este suma maximă pe care o poate obține. În cazul meu, se pare că „rata” limitează linkul la valoarea specificată. Acesta nu este cu siguranță comportamentul dorit și așteptat.

Dacă setez parametrul „rate” al clasei rădăcină la aceeași valoare ca „ceil”, adică 1000mbit, nu are loc nicio prioritizare și lățimea de bandă disponibilă este împărțită în mod egal între toate fluxurile. Acesta nu este comportamentul dorit, deoarece în cazul fluctuațiilor lățimii de bandă disponibile, traficul anterior va obține mai puțin de 1,67 Mbit/s

Am înțeles greșit sensul parametrului „rata” în clasa rădăcină? Este această problemă legată cumva de alți parametri HTB, cum ar fi „cuantică”? De asemenea, am observat că fiecare clasă are o cantitate negativă de jetoane în timpul transmiterii datelor. Este rău? Dacă da, ce parametri ar trebui să reglez și cum?

Multumesc anticipat!

Puncte:0
drapel us

Parametrul plafon nu a avut efect în clasa rădăcină, ar trebui să setați doar rata.

Dacă obiectivul dvs. este să faceți parte din plafonul claselor pentru copii, puteți utiliza hfsc în loc de HTB, dar nu vă va împiedica să solicitați rata maximă chiar dacă nu aveți suficientă lățime de bandă.

Dacă scopul tău este să faci față unei conexiuni la internet fluctuente, nu va funcționa în acest fel, deoarece limitați partea de încărcare, iar cea de descărcare tot nu va fi prioritizată. Puteți căuta ifb pentru a limita lățimea de bandă de descărcare.

În orice caz, tc nu va putea detecta lățimea de bandă disponibilă reală. Asigurați-vă că utilizați fq_codel, totuși, pentru o gestionare mai bună a cozilor, bbr pentru TCP și un nucleu Linux recent, astfel încât să limitați impactul de a putea cere mai multă lățime de bandă pe care o aveți.

drapel jp
Vă mulțumim pentru sugestiile despre HFSC și BBR! Clarificare la prima propoziție: deci, pentru clasa rădăcină, parametrul „rate” are rolul de „plafon” prin limitarea strictă a lățimii de bandă disponibilă pentru qdisc?
setenforce 1 avatar
drapel us
Da, în clasa rădăcină, valoarea ratei este utilizată pentru rate și plafon.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.