Problemă: Când tc HTB sau CQB este folosit pentru modelarea traficului, primele două pachete care sunt trimise după un interval de timp sunt trimise înapoi în spate așa cum sunt înregistrate în jurnalul pcap.
Am un computer intermediar cu ubuntu 18.4 cu redirecționarea în rețea activată. Rulez tc cu HTB pentru a modela traficul pentru a avea o ieșire constantă de bitrate pe portul de ieșire.
Clientul solicită bucățile cu dimensiuni variabile de la server. Serverul trimite datele codificate de transfer de fragmente cu un interval de 200 ms între fiecare bucată către client. Cu configurația mea având computerul intermediar, aceste pachete sunt trecute prin modelul de trafic pe computerul intermediar pentru a obține un bitrate fix de 500 kbps.
Pe măsură ce dezactivez descărcarea (TSO și GRO), fiecare n octeți sunt împărțiți în cadre de către pcap.
Majoritatea pachetelor 1448B au un interval de timp apropiat de 24,224 ms, care este de așteptat la 500 kbps
Problemă: Deși cadrele ajung în succesiune, intervalul lor de timp de sosire nu este consecvent.
Al doilea pachet mare (1448B) după intervalul de 200 ms vine întotdeauna aproape spate la spate cu primul pachet.
Ultimul pachet în bucată (654B) sosește cu întârziere (24,224 ms în loc de 10,464 ms în exemplul din imaginea atașată)
Captură de ecran a timpurilor
Intervalele de sincronizare dintre pachete.
Comanda TC cu HTB:
tc qdisc del dev enx00e04c080ecf root 2> /dev/null > /dev/null
tc qdisc add dev enx00e04c080ecf root handle 1:0 htb implicit 2
tc class add dev enx00e04c080ecf parent 1:1 classid 1:2 htb rate 500kbit ceil 500kbit burst 10 cburst 10 prio 2
tc filter add dev enx00e04c080ecf protocol ip parent 1:0 u32 match ip dst 192.168.2.103 flowid 1:2
Dacă nu fac nicio greșeală în calcul, cred că problema s-ar putea datora manipulării token-ului în tc pe care îl folosesc pentru modelarea traficului.
Cred că tokenurile sunt acumulate în timpul inactiv și când următorul pachet este primit, trimite cele două pachete înapoi în spate.
din al treilea pachet rata de consum de token se stabilește.
Dacă asta se întâmplă, aș dori să știu dacă există o modalitate de a evita utilizarea jetoanelor acumulate pentru al doilea pachet din bucată.
Am încercat diverse opțiuni în comanda tc
De asemenea, am încercat să folosesc CQB - comanda de mai jos
Referinta: https://lartc.org/lartc.html#AEN2233
Observare:
reducerea exploziei = 10 mărește ușor decalajul dintre primul și al doilea pachet.
tc Cu CQB:
tc qdisc del dev enx00e04c080ecf root 2> /dev/null > /dev/null
tc qdisc add dev enx00e04c080ecf root handle 1: cbq avpkt 5000 bandwidth 10mbit
tc class add dev enx00e04c080ecf parent 1: classid 1:1 cbq rate 500kbit allot 5000 prio 5 delimitat izolat
tc class add dev enx00e04c080ecf parent 1:1 classid 1:10 cbq rate 500kbit allot 5000 prio 1 avpkt 5000 bounded
tc class add dev enx00e04c080ecf parent 1:1 classid 1:20 cbq rate 500kbit allot 5000 avpkt 5000 prio 2
tc filter add dev enx00e04c080ecf protocol ip parent 1:0 u32 match ip dst 192.168.2.103 flowid 1:10
tc filter add dev enx00e04c080ecf parent 1: protocol ip prio 13 u32 match ip dst 0.0.0.0/0 flowid 1:20
