[Cake] small cake_hash optimization?
moeller0 at gmx.de
Thu Nov 23 03:00:31 EST 2017
> On Nov 22, 2017, at 19:43, Pete Heist <peteheist at gmail.com> wrote:
>> On Nov 22, 2017, at 7:33 PM, Dave Taht <dave.taht at gmail.com> wrote:
>> On Wed, Nov 22, 2017 at 4:37 AM, Pete Heist <peteheist at gmail.com> wrote:
>>> Ok, at least a little crude testing with sar:
>>> ~10% less cake CPU at GigE in this case?
>> Divides do hurt, particularly if you can't do them out of order. But
>> that seems like a lot.
> Hrm, I tried a second test to make sure fairness still works (it does) but this time got a slight _negative_ result (rrul_be fair tab). So this calls into question whether or not my testing method is very good, and also whether or not the change actually helps much.
> This time I used "cake unlimited besteffort dual-srchost overhead 64 mpu 84” (overheads from Sebastian, just rely on bql).
I should have mentioned "overhead 64 mpu 84" only make sense in combination with a shaper limit (well, they will make sure the cake statistics will be more reflective of what is happening on the ethernet wire, but I am not sure whether that is worth the run-time cost the overhead calculation incurs).
Somewhat unrelated, I wondered about all the excitement about irtt and cloned the repository to my mac, and was absolutely delighted to realize that irtt will also effortlessly work under macos. I only have run the demo from the readme.md with both client and server running at the same machine, but I got results that look reasonable on first sight (but I admit I really do not know exact;y what to expect). This is really great!
> I might try again with 950mbit limiting, and ‘perf’ instead.
> Also I noted that the ‘lan’ keyword seemed to adversely affect host fairness, so I stopped using it. I’ll address that separately when there’s time.
>>> What’s a better tool for timing
>>> kernel module functions?
>> Use "perf"
> Ok, will see if I can give it a try.
> Cake mailing list
> Cake at lists.bufferbloat.net
More information about the Cake