Re: [Cerowrt-devel] [Codel] [Bloat] Latest codel, fq_codel, and pie sim study from cablelabs now available

[Andrew McGregor <andrewmcgr@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1705 bytes --]

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 <eric.dumazet@gmail.com> 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
>

[-- Attachment #2: Type: text/html, Size: 2427 bytes --]