Hi Dave,
> On Sep 19, 2018, at 19:02, Dave Taht <[email protected]> wrote: > > thx! You are welcome, but does this actually work for you? I want to clean up things by removing the old burst scaling mode, but want/need confirmation that the new duration based method actually works as intended. (My next step then will be putting the axe on the quantum scaling, where I plan to use exactly the same size as for burst, on the theory that worst case we can only push bust bytes to the NIC and should try to service the other priority tiers at latest on the next HTB execution iteration). Best Regards Sebastian > On Wed, Sep 19, 2018 at 6:28 AM Sebastian Moeller <[email protected]> wrote: >> >> Hi Dave, hi All, >> >> so I tried to run with this idea and prototyped something into the >> burst_by_duration branch at the sqm repository. Would be interested to hear >> whether that does "the right thing" with your APU or on other's devices? The >> key variable is TARGET_BURST_DUR_MS in defaults.sh. Let me know how this >> performs for you (or whether there are bugs). As Toke proposed elsewhere I >> will try to streamline that branch to only configure burst size by duration >> so expect some changes in organization, but it should keep functional. >> >> Best Regards >> Sebastian >> >>> On Sep 11, 2018, at 10:20, Dave Taht <[email protected]> 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. >> > > > -- > > Dave Täht > CEO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-669-226-2619 _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
