CoDel AQM discussions
 help / color / mirror / Atom feed
From: Jonathan Morton <chromatix99@gmail.com>
To: Dong Mo <montedong@gmail.com>
Cc: codel@lists.bufferbloat.net
Subject: Re: [Codel] New to codel-- how to run codel on a linux box?
Date: Thu, 5 Dec 2013 22:06:56 +0200	[thread overview]
Message-ID: <269B8D3A-09C7-411E-9482-27CAA898A29F@gmail.com> (raw)
In-Reply-To: <CAAUsAoQ9dRUEAXU6P90jphbTe7Xp50NrAG=_Miqy8Q400g1SGw@mail.gmail.com>


On 5 Dec, 2013, at 9:49 pm, Dong Mo wrote:

> 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.
> 
> However, if I am not using sfq, and send only one flow over this link, the delay will explode again.
> 
> So is sfq here cut off the queue length somehow? How should I make a bufferbloat fair queue on linux box using tc qdisc?

How are you measuring the delay?  Ping?

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.

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.

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.

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.

 - Jonathan Morton


  reply	other threads:[~2013-12-05 20:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-23  5:04 Dong Mo
2013-11-23 10:23 ` Jonathan Morton
2013-11-23 14:43   ` Dave Taht
2013-12-05 19:36     ` Dong Mo
2013-12-05 19:49       ` Dong Mo
2013-12-05 20:06         ` Jonathan Morton [this message]
2013-12-05 20:21           ` Dong Mo
2013-12-05 21:03             ` Toke Høiland-Jørgensen
2013-12-05 22:29               ` Dong Mo
2013-12-05 23:25                 ` Toke Høiland-Jørgensen
2013-12-05 23:28                   ` Dong Mo
2013-12-05 23:43                     ` Toke Høiland-Jørgensen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/codel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=269B8D3A-09C7-411E-9482-27CAA898A29F@gmail.com \
    --to=chromatix99@gmail.com \
    --cc=codel@lists.bufferbloat.net \
    --cc=montedong@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox