Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Jonathan Morton <chromatix99@gmail.com>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: codel@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] [Codel] The next slice of cake
Date: Wed, 18 Mar 2015 10:41:41 +0200	[thread overview]
Message-ID: <8BA791D1-E86E-4411-9081-1D1DC3D3D810@gmail.com> (raw)
In-Reply-To: <B31E1817-7749-4AFC-91D6-46FF234C8E99@gmx.de>

> I wonder, are the low priority classes configured with a guaranteed minimum bandwidth to avoid starvation? And will they opportunistically grab all left over bandwidth to fill the pipe? Then speed test should just work as long as there is no competing traffic…

The problem is that, in the present version, *only* the bulk/background class can use the full pipe.  Best effort gets a large fraction as its limit, but it’s not full.  Existing speed tests use best-effort traffic, and that’s not likely to change soon.

The next version should change that.

> I am probably out of my mind, but couldn't it help if cake would allow a fixed cycle mode where it would process 50ms or so worth of packets pass them to the interface, and then sleep until the next 50ms block start. This should just be a fallback mode to not degrade badly under overload…

There is already such a mode to cope with limited-resolution timers and the existing overheads.  Without it, the Pentium-MMX is limited to a rather low rate (since it then has to wait for a timer interrupt for alternate packets).  At 50Mbps+, it’s not too far off what it can bridge without shaping (60Mbps+).  For some reason, the little CPE boxes still lose more performance than that to shaping.

Note that due to the very nature of shaping, the link is always either effectively idle (in which case an arriving packet is dispatched immediately, without waiting for a timer), or overloaded (in which case packets are delivered according to a schedule).  The question is whether the shaping rate also overloads the hardware.

In any case, bursting for fifty whole milliseconds at a time would absolutely *destroy* cake’s latency performance.  I’m not going to do that.  Accommodating timer performance is the only concession to bursting I’m willing to make.

> I think the highest priority band should only get its bandwidth quota, and have no silent priority demotion; but otherwise I think that idea that classes can pick up unused bandwidth sounds sane, especially for best effort and background.

Let’s see how well it works this way.  It should be fairly easy to adjust this aspect of behaviour later on.

 - Jonathan Morton


  reply	other threads:[~2015-03-18  8:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-17 20:08 [Cerowrt-devel] " Jonathan Morton
     [not found] ` <1426624485.8558.63.camel@capibara.fcal.uner.edu.ar>
2015-03-17 21:33   ` Jonathan Morton
2015-03-17 22:38     ` Dave Taht
2015-03-18  7:28       ` Sebastian Moeller
2015-03-18  7:22 ` [Cerowrt-devel] [Codel] " Sebastian Moeller
2015-03-18  8:41   ` Jonathan Morton [this message]
2015-03-18 10:39     ` Sebastian Moeller

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/cerowrt-devel.lists.bufferbloat.net/

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

  git send-email \
    --in-reply-to=8BA791D1-E86E-4411-9081-1D1DC3D3D810@gmail.com \
    --to=chromatix99@gmail.com \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=codel@lists.bufferbloat.net \
    --cc=moeller0@gmx.de \
    /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