Cool, well I for one would like to see the APU be able to handle higher speeds, for FreeNet’s backhaul, at least. Although frankly, I’ve not definitively witnessed any significant bloat in their backhaul yet with production traffic.

A good number of their routers are still ALIX (https://www.pcengines.ch/alix2d2.htm), all of which are on an upgrade list. These don’t do hfsc + sfq on kernel 2.6.26 much beyond about 70 Mbit. Not a problem to focus on… :)

On Sep 4, 2018, at 11:16 PM, Dave Taht <dave.taht@gmail.com> wrote:

my guess is that burst and cburst should scale roughly as a function
of the bytes that can fit into 1ms.
On Tue, Sep 4, 2018 at 2:14 PM Dave Taht <dave.taht@gmail.com> wrote:

making htb's cburst and burst parameters 64k gets the APU2  up to
where it can shape 900mbits. 3 ksoftirq handlers start getting cpu
time, and we end up 54% idle to achiefe that.

I should really go around running my own old code. I was deeply
involved in sqm when we still had to run at sub 200mbit levels. since
then it's been
mostly tbf (burst 64k) + fq_codel or cake, and me ignoring various bug
reports about it not scaling well enough at higher rates.
On Tue, Sep 4, 2018 at 12:59 PM Dave Taht <dave.taht@gmail.com> wrote:

less than scientifically (via monitoring top) - on the apu2

100Mbit sqm (htb + fq_codel)

fq_codel_mainline | fq_codel_fast
idle 78.8                | 83.5 |
si    20                   | 16.1 |

Yea! But:

900Mbit sqm (htb + fq_codel)

fq_codel_mainline | fq_codel_fast
idle 74.4                | 74.4 |
si    25                   | 25.1 |

Here: completely bottlenecked on ksoftirqd - and I only get 340Mbits
out of the 900mbit setting. quantum 96k and burst of 15000. Haven't
fiddled with higher values yet...