<div dir="ltr">That makes a lot of sense.<div><br></div><div>I missed the point the fq separate ICMP and tcp flows.</div><div><br></div><div>My current setting is </div><div><br></div><div>Ubuntu sender A with codel (htb and fq and fq_codel happens here) ---1G---freebsd ipfw machine inject link delay of 20ms------1G-----Ubuntu receiver B machine.<br>
</div><div><br></div><div>What I am trying to do is measure the delay of packets of the same flow experienced in A under different queuing policies (sfq or fq_codel). </div><div><br></div><div>Is there a simple way to do this?</div>
<div><br></div><div>Thanks</div><div>-Mo</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/12/5 Jonathan Morton <span dir="ltr"><<a href="mailto:chromatix99@gmail.com" target="_blank">chromatix99@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On 5 Dec, 2013, at 9:49 pm, Dong Mo wrote:<br>
<br>
> And sending packet from the sender, where qdisc is set, to the receiver, the queuing delay is quite small and is approximately the same as when fq_codel enabled.<br>
><br>
> However, if I am not using sfq, and send only one flow over this link, the delay will explode again.<br>
><br>
> So is sfq here cut off the queue length somehow? How should I make a bufferbloat fair queue on linux box using tc qdisc?<br>
<br>
</div>How are you measuring the delay?  Ping?<br>
<br>
This is relevant because ICMP (ping) occupies a different "flow" than the TCP stream(s) you are loading the link with.  SFQ and fq_codel both service flows fairly, ensuring that each gets some traffic through continuously.  So your pings have low latency even if SFQ's queue is full.<br>

<br>
The difference is that fq_codel keeps the queue of each flow short, while SFQ allows each queue to grow up to the limit.  The latter behaviour is adequate in some situations, but has some bad consequences such as slow recovery from packet loss on each flow.  And because SFQ can *only* keep the queue within limits by dropping packets, there *will* be packet loss on a regular basis unless the receive window of the TCP flow is exhausted first.  By contrast fq_codel is ECN-aware, so on ECN-enabled flows it can avoid dropping packets altogether while still keeping latency low enough for rapid recovery if packet loss occurs anyway.<br>

<br>
It also often happens that packets dropped due to a full queue happen to be at the end of a TCP connection, for which detection and recovery of the problem is much slower (and usually on very human-visible timescales) than in the middle of a connection.  In this case SFQ is no help, because it also drops from teh tail of the queue, where the last packets of a connection arrive.  By contrast fq_codel drops from the head of the queue when required (ie. when ECN is not available), so unless two connections share a flow (rare but not impossible), the lost packet will always be from the middle of a connection and will be retransmitted quickly.<br>

<br>
That is the sort of behaviour you should test for when comparing fq_codel and SFQ.  A simple ping test under load is satisfied by both qdiscs.<br>
<span class="HOEnZb"><font color="#888888"><br>
 - Jonathan Morton<br>
<br>
</font></span></blockquote></div><br></div>