[Cake] Cake vs fq_codel and c/burst on an ER-X bridge

Sebastian Moeller moeller0 at gmx.de
Tue Sep 11 04:43:17 EDT 2018

Hi Dave,

> On Sep 11, 2018, at 10:30, Dave Taht <dave.taht at gmail.com> wrote:
> On Tue, Sep 11, 2018 at 1:20 AM Sebastian Moeller <moeller0 at gmx.de> wrote:
>> Hi Dave,
>>> On Sep 11, 2018, at 10:20, Dave Taht <dave.taht at gmail.com> wrote:
>>> What I "fixed" was on the apu2 with the burst/cburst change, I went
>>> from completely bottlenecked on one softirq to having 3 eat cpu, and
>>> from 400mbps to 900mbps. Now, that's a quad core and the e1000 (?)
>>> driver. The edgerouter X is a dual core, and you did see a small
>>> improvement in throughput, but I'd hoped for more.
>> Well, assuming my intuitions about how burst/cburst ameliorate the issue, we might simply have to say accept an additional 5ms delay/jitter to make it perform better. It is basically the same batching approach that always helps throughput of a cyclic process can not be repeated often enough, simply do more per iteration...
>> Best Regards
>>        Sebastian
> I buy what you are saying. I just wished it was a magic bullet for
> other than the apu2!

I guess I will have a look at exposing burst in the gui/config file to allow easier testing. (I aim for defaulting to the automatic mode we currently use, but will also look at potentially changing the calculations).
I wonder to what degree htb's quantum is at play again after that. If I understand correctly quantum defines the granularity of dequeuing the different priority tiers, so the higher quantum the higher the choppyness/lumpiness of packets of different tiers, no? If this is true, shouldn't quantum also be defined in milliseconds instead of size, so that we have a better handle on the potential latency cost of doing so?

Best Regards

> -- 
> Dave Täht
> CEO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-669-226-2619

More information about the Cake mailing list