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