Am 20.08.2019 um 18:24 schrieb Dave Taht:
On Tue, Aug 20, 2019 at 5:09 AM Sebastian Gottschall
<s.gottsch...@newmedia-net.de> wrote:
:-) i'm following this list and yes we are working on bringing cake in :-)
Yea! thx for being on the list!
is there any question behind this link from your side?
I just wanted to make people here aware that it was happening.
Is there a build now?
the first builds with cake are already out yes, but unfinished. we
started then to rewrite major parts of the qos code. i expect to push out
a new build tomorrow. it will still not use the full potential of cake
since we have to bring all together with the priority and ndpi and
filter based filter together
with the cake scheduler. but it works so far and will be better in the
next days and weeks after we have found a solution for it. cake is more
a all in wonder solution
so we have to use the features of cake itself to reimplement the
priorisation classes
If I had any one principal request it would be to make sure the dd-wrt
gui (if one is made) exposes the link layer parameters. Getting the
framing wrong is about the biggest error I see in the deployment:
https://www.youtube.com/watch?v=LjJW_s5gQ9Y
i have seen this already. out plan here is that the user specifies the
internet connection type like vdsl2, cable, whatever in case of cake
which then will be used
as argument
Other nifty cake features:
"wash" and "besteffort" are important on some cablecos that remark
traffic to CS1
"nat" is dang useful if you are natting
ack-filter helps on really slow asymmetric networks on the slow side only.
So, like, my defaults would be
in: nat wash besteffort # triple-isolate bandwidth X etc
out: nat ack-filter # if > 10x1 down/up ratio
my finding for damn slow internet < 2000 kbit upstream that we need to
handle rtt like codel with the formula
rtt = 50 - (uprate / 50)
which gives a rtt of 10 at 2000 kbit. otherwise its not working good.
for the rest i will consider your defaults for our tests.
And make sure the link layer settings are exposed in the gui. I really
don't know how much
"washing" is needed outside the cablecos, taking packet captures of
various isps to see how often
dscp bits are mangled nowadays would be good. besteffort on inbound
saves some on cpu.
dscp might be problematic for isps like orange in france and other fiber
isps i have found in spain and netherlands.
all these isps expect dscp classes to be set for outbound traffic
depending on the traffic type. (iptv, voice and internet). this together
is also
mapped to vlan priorities again internally. so using the dscp bits might
be problematic for cake since it clears out the dscp flags and so
internet simply doesnt work anymore
for these isps (or just with modem 56k speed)
Are you using the out of tree version or mainline? Out of tree has
some experimental SCE work
that I'd love to see tested at more scale but not actually shipped at this time.
out of tree straight from git with modifications to be compatible to my
kernels since your compatiblity layer is mmh not perfect.
some compat layer you made doesnt work since they already got backported
to the latest upstream kernel versions. so just some refinement.
nothing special or much work
Due to how cpu intensive cake can be (on inbound) I've been working on
a faster, less feature-full fq_codel, it's here:
https://github.com/dtaht/fq_codel_fast
i reviewed it and also tried to compile it with success. problem is,
that code parts of it are looking unfinished with debug printks etc.
this is why i stopped at that point since i thought its unfinished. but
i have added it already to my code tree and added the required parts to
compile
it with all of my kernels (compat layer for older kernels or lets say
#ifdef hell)
I hate the idea of fq_codel one way, cake the other, but tbf +
fq_codel_fast seems to work well at
~1gbit on my apu2 and cake doesn't. I'd originally planned to try and
make a multi-core shaper out
of it, but sce distracted me....
multicore would be nice since alot of home routers are coming with up to
4 native cpus right now. (ipq8065 has 1.8 ghz and dual core. ipq40xx has
4 cores but just 700 mhz and is 4 times slower per core and mhz, so it
makes sense here)
i'm using a APU as internet router as well btw
Having more folk on board benching stuff on modern non-x86 platforms
would be good.
yeah no problem. we mainly test on a gateworks laguna armv6 platform in
my company, but most reponse will come from broadcom arm northstar and
qca ipq platforms from the community
but i hope i also get feedback from slower platforms like mips ar7240 etc
Another cake feature is that you can get all the benefits on a normal
ethernet (with bql) *without turning the shaper on* but we have not
benchmarked that either vs a vs fq_codel or fq_codel_fast
from the response i got from the early experiments is that cake performs
much better in typical bufferfloat tests than fq_codel. but i will see
how my latest version now works
which fully integrated it.
Sebastian
Have fun!
Here's the first paper: https://arxiv.org/pdf/1804.07617.pdf
Sebastian
Am 18.08.2019 um 18:33 schrieb Dave Taht:
https://svn.dd-wrt.com/ticket/5796
_______________________________________________
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
