<div dir="ltr">To add to discrepancies tbf so far as I remember broke up gso superpackets into packets, htb did not. <div><br></div><div>How all the aqms behave with superpackets is insufficiently explored. This is why cake made breaking</div><div>up gso packets into regular packets the default. </div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 25, 2024 at 3:47 PM Joerg Deutschmann via Bloat <<a href="mailto:bloat@lists.bufferbloat.net">bloat@lists.bufferbloat.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Thanks Max and Stephen,<br>
<br>
>>  From my experience (experimented with it last year), it still behaves<br>
>> weirdly. You can use htb for the shaping and you can create delay using<br>
>> netem by using it on another (virtual) host on a link that does not have<br>
>> any other qdiscs and where the link is not the bottleneck.<br>
Yes, I did some quick tests and saw that this works:<br>
> sudo tc qdisc add dev eth0 root handle 2: tbf rate 200Mbit burst 4542 limit 500000<br>
> sudo tc qdisc add dev eth0 parent 2: handle 3: fq_codel<br>
but this does not work:<br>
> sudo tc qdisc add dev eth0 root handle 1: netem delay 20ms limit 10000000<br>
> sudo tc qdisc add dev eth0 parent 1: handle 2: tbf rate 200Mbit burst 4542 limit 500000<br>
> sudo tc qdisc add dev eth0 parent 2: handle 3: fq_codel<br>
<br>
Adding netem delay to a separate host or adding it to the ingress qdisc <br>
(as described by Dave) does the trick.<br>
<br>
<br>
> Yes, netem has expectations about how inner qdisc behaves,<br>
> and other qdisc used as inner have expectations about how/when packets<br>
> are sent. There is a mismatch, not sure if it is fixable with in the<br>
> architecture of how Linux queue disciplines operate.<br>
For the sake of completeness, here's the quote from the netem man page:<br>
> Combining netem with other qdisc is possible but may not always work because netem use skb control block to set delays.<br>
:-)<br>
<br>
> <br>
> The best way is to use netem on an intermediate hop and not expect<br>
> it to work perfectly when used on an endpoint. The same is true of Dummynet<br>
> and other network emulators; they are uses as man-in-the-middle systems.<br>
Still I guess it can be tricky if netem delay + tbf shaping + fq_codel <br>
shall be used altogether.<br>
<br>
This paper mentions that the order tbf/netem or netem/tbf matters <br>
(section 4.1.1), but does not mention fq_codel:<br>
<a href="https://atlas.cs.uni-tuebingen.de/~menth/papers/Menth17-Sub-2.pdf" rel="noreferrer" target="_blank">https://atlas.cs.uni-tuebingen.de/~menth/papers/Menth17-Sub-2.pdf</a><br>
_______________________________________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net" target="_blank">Bloat@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Dave Täht CSO, LibreQos<br></div></div></div>