From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id F29F321F1A6; Wed, 8 May 2013 18:45:44 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id v20so2535929lbc.21 for ; Wed, 08 May 2013 18:45:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Ilx5mmi5D8dxHy4Lm33dbsoLSnmhnFTqk9ZxUC8b26U=; b=LYQr6LAd89BefUlCPsRRV/sxERPUPrfFqLClPRlIrPRqGGIiPhLFKLrQ2hjkPxDdti eMfDq/rTHqyTa5188AFw6Qiy+cjTr+q7cQNlJLaXneMRpNQJ8uxQwEp6XoFMCnGRpKDG P6/WSZpC+/hpU0UJixecNnzhjCJyy4AKN0Q3sACL6LLBgOBLAyob890KGpnD5ILkxvDa YJNzYM4mmeNHwZ7+ApHhwGBewpMu0shYLU736X26sThTe7gNataC0dKNmV+FrJHTdVQx j/QHPeYxMyFDigcwX0BtDrdkMa0ZnzqsPv48cWWgw92tmueO+chTeDQxvqgOIow2biY4 qBQg== MIME-Version: 1.0 X-Received: by 10.152.29.165 with SMTP id l5mr4389966lah.8.1368063941733; Wed, 08 May 2013 18:45:41 -0700 (PDT) Received: by 10.112.131.71 with HTTP; Wed, 8 May 2013 18:45:41 -0700 (PDT) In-Reply-To: <1368053697.13473.28.camel@edumazet-glaptop> References: <19404.1367933465@sandelman.ca> <1367958622.13473.10.camel@edumazet-glaptop> <1368053697.13473.28.camel@edumazet-glaptop> Date: Thu, 9 May 2013 11:45:41 +1000 Message-ID: From: Andrew McGregor To: Eric Dumazet Content-Type: multipart/alternative; boundary=089e0158c00a46f3b904dc3f3526 Cc: Wes Felter , codel@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net, bloat@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] [Codel] [Bloat] Latest codel, fq_codel, and pie sim study from cablelabs now available X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 01:45:45 -0000 --089e0158c00a46f3b904dc3f3526 Content-Type: text/plain; charset=ISO-8859-1 Strict priority plays very badly with unmanaged devices... HTB or DRR will have many fewer 'the network is broken' corner cases. Or indeed, fq_codel extended with more queue lists and a matrix of transition rules. On Thu, May 9, 2013 at 8:54 AM, Eric Dumazet wrote: > On Wed, 2013-05-08 at 15:25 -0700, Dave Taht wrote: > > > > Heh. I am hoping you are providing this as a negative proof!? as the > > strict prioritization of this particular linux scheduler means that a > > single full rate TCP flow in class 1:1 will completely starve classes > > 1:2 and 1:3. > > > > Some level of fairness between service classes is needed too. My most > > common setting for the "cake" shaper has been 20% minimum for the > > background traffic, for example. I am unsure if codel is really the > > right thing for the highest priority qdisc, as everything > > > > PRIO qdisc does strict priority, like pfifo_fast. > > If your high prio traffic is also using 100% of the bandwith, then there > is a fundamental problem about classifying this so called high prio > traffic. > > On my hosts, high prio traffic uses less than 0.1 % of the bandwidth, > so I do not need to have DRR kind of setup. > > And the low priority traffic has no minimum guaranteed bandwidth. > > There is no 'magic solution' for every needs. The solution I gave is > good enough if you need to have some strict priorities, as a replacement > to current pfifo_fast, and if all traffic is not miss classified. > > A setup using DRR instead of PRIO is also possible. > > > _______________________________________________ > Codel mailing list > Codel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/codel > --089e0158c00a46f3b904dc3f3526 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Strict priority plays very badly with unmanaged devices...= HTB or DRR will have many fewer 'the network is broken' corner cas= es.

Or indeed, fq_codel extended with more queue l= ists and a matrix of transition rules.


On Thu,= May 9, 2013 at 8:54 AM, Eric Dumazet <eric.dumazet@gmail.com>= wrote:
On Wed, 2013-05-08 at 15:2= 5 -0700, Dave Taht wrote:


> Heh. I am hoping you are providing this as a negative proof!? as the > strict prioritization of this particular linux scheduler means that a<= br> > single full rate TCP flow in class 1:1 will completely starve classes<= br> > 1:2 and 1:3.
>
> Some level of fairness between service classes= is needed too. My most
> common setting for the "cake" shaper has been 20% minimum fo= r the
> background traffic, for example. I am unsure if codel is really the > right thing for the highest priority qdisc, as everything
>

PRIO qdisc does strict priority, like pfifo_fast.

If your high prio traffic is also using 100% of the bandwith, then there is a fundamental problem about classifying this so called high prio
traffic.

On my hosts, high prio traffic uses less than 0.1 % of the bandwidth,
so I do not need to have DRR kind of setup.

And the low priority traffic has no minimum guaranteed bandwidth.

There is no 'magic solution' for every needs. The solution I gave i= s
good enough if you need to have some strict priorities, as a replacement to current pfifo_fast, and if all traffic is not miss classified.

A setup using DRR instead of PRIO is also possible.


_______________________________________________
Codel mailing list
Codel@lists.bufferbloat.net<= /a>
= https://lists.bufferbloat.net/listinfo/codel

--089e0158c00a46f3b904dc3f3526--