On 01/06/16 11:13, Dave Täht wrote:
I still think squashing is very important, and essentially required by
several rfcs.
I'm now wondering if we're falling into a terminology trap. The original
tc/cake implementation of 'squash' was effectively to use 'besteffort'
(ie diffserv1) ie. igno
Gentlemen,
Two pull requests https://github.com/dtaht/sch_cake/pull/26 &
https://github.com/dtaht/tc-adv/pull/11
These drop the collection of last packet's length for stats purposes.
I've not dropped maxlen as I have personally found that *incredibly*
useful in working out what overheads li
On 01/06/16 12:41, moeller0 wrote:
Hi Toke,
I'm guessing this was probably discussed before and I've simply
forgotten; but why does this (rewriting dscp bits) need to be part of
the qdisc when you can do it with iptables?
Well, cake looks at the DSCP bits already, if it can do the re
On 01/06/16 13:25, Benjamin Cronce wrote:
I'm just going to ask two questions just to reflect on
1) Ideally, regardless of platform, should an AQM or scheduler have the
responsibility of changing anything other than ECN?
2) Should you be deciding the responsibility of CAKE based on the
imp
On 01/06/16 15:00, Jonathan Morton wrote:
On 1 Jun, 2016, at 14:40, Kevin Darbyshire-Bryant
wrote:
Not updating another variable (memory write) for each packet may help cake's
CPU usage a little.
I’ll think about this one.
I don’t think it should gate the LEDE merge (nor shou
Greetings All,
In a bid to create yet another day of cake controversy, here's my latest
pull request https://github.com/dtaht/tc-adv/pull/12
It removes all the atm/ptm/ethernet specific overhead keywords.
I find myself largely in agreement with Sebastian where he said:
"
I would prefer very
Hi All,
Cake uses the flow dissector API to do flow hashing...including per host
flows for dual/triple isolation. The unfortunate bit is that the qdisc
inevitably gets placed after packets have been NATed on egress and
before they've been de-NATed on ingress.
When mentioned before Johnathan
Dear All,
For those interested, Jonathan Morton's CAKE qdisc has made it into
LEDE. See
https://git.lede-project.org/?p=source.git;a=commit;h=1a3c56f8322d27f4652d23eb7dc14a45e1631e1c
for proof :-)
The package to install for your target is 'kmod-sched-cake'
https://downloads.lede-project.or
Hi All,
I was nosing through linux-netdev last night when I saw this fix for
qdisc backlog reporting issues with NET_XMIT_CN in fq_codel:
http://marc.info/?l=linux-netdev&m=146506223800713&w=2
I had a nose at CAKE but couldn't quit work out if a similar issue is
present but I suspect it is.
On 07/06/16 15:50, Jonathan Morton wrote:
On 7 Jun, 2016, at 14:20, Kevin Darbyshire-Bryant
wrote:
I had a nose at CAKE but couldn't quit work out if a similar issue is present but I
suspect it is. Certainly if Eric can't get it right "My prior attempt to fix the
back
200ac:/etc/config# /etc/init.d/sqm start
SQM: Stopping SQM on eth0
SQM: Starting SQM script: piece_of_cake.qos on eth0, in: 10 Kbps,
out: 9000 Kbps
SQM: piece_of_cake.qos was started on eth0 successfully
On Tue, Jun 7, 2016 at 2:53 AM, Kevin Darbyshire-Bryant
wrote:
Dear All,
For those inte
On 07/06/16 18:00, Dave Taht wrote:
possibly 1. tc - 4.4.0-1 - Traffic control utility is what I have.
Yes, you peaked too soon :-) Should be tc 4.4.0-2 :-)
KDB
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinf
On 07/06/16 18:23, Dave Taht wrote:
On Tue, Jun 7, 2016 at 10:04 AM, Kevin Darbyshire-Bryant
wrote:
On 07/06/16 18:00, Dave Taht wrote:
possibly 1. tc - 4.4.0-1 - Traffic control utility is what I have.
Yes, you peaked too soon :-) Should be tc 4.4.0-2 :-)
KDB
OK, I will wait a day
On 09/06/16 21:58, Dennis Fedtke wrote:
Hi
Currently im running lede + cake + sqm_scripts and i have some questions:
1. What is considered the "optimal" setup atm for cake?
e.g. which cake script should i use piece or layer cake?
Piece of cake doesn't use diffserv hence doesn't 'soft shape' t
Greetings All,
May this message find you in acceptable health and reasonable humour :-)
Possibly/probably as a result of CAKE getting into LEDE I note a few
people saying 'bufferbloat.net' is down. This is unfortunate just at a
time when a hoped for uptick in interest factor may well be upon
On 10/06/16 10:02, Toke Høiland-Jørgensen wrote:
Kevin Darbyshire-Bryant writes:
Possibly/probably as a result of CAKE getting into LEDE I note a few people
saying 'bufferbloat.net' is down. This is unfortunate just at a time when a
hoped for uptick in interest factor may well
On 07/06/16 16:05, Kevin Darbyshire-Bryant wrote:
On 07/06/16 15:50, Jonathan Morton wrote:
On 7 Jun, 2016, at 14:20, Kevin Darbyshire-Bryant
wrote:
I had a nose at CAKE but couldn't quit work out if a similar issue
is present but I suspect it is. Certainly if Eric can't ge
On 27/06/16 04:56, Jonathan Morton wrote:
On 4 Jun, 2016, at 22:55, Jonathan Morton wrote:
COBALT should turn out to be a reasonable antidote to sender-side cheating, due
to the way BLUE works; the drop probability remains steady until the queue has
completely emptied, and then decays slowl
On 28/06/16 03:51, Jonathan Morton wrote:
On 27 Jun, 2016, at 18:18, Kevin Darbyshire-Bryant
wrote:
How do you feel about switching that package to the cobalt variant for wider
stress testing?
I think the best way to do that would be to merge the cobalt branch to master,
but retaining it
On 28/06/16 16:33, Jonathan Morton wrote:
On 28 Jun, 2016, at 11:40, Kevin Darbyshire-Bryant
wrote:
Would you like me to split out 'sparse_flows' and 'decaying_flows'?
No. A flow with BLUE active won’t be in “decaying flows” continuously until
traffic ceases on it,
On 28/06/16 18:37, Kevin Darbyshire-Bryant wrote:
Ok, so I've pushed the 'split u32 last_len into 2 u16' tweaks to
tc-adv & sch_cake.
I will push a corresponding change into LEDE for the iproute2 (tc)
package. The push of sch_cake itself will happen after I
On 29/06/16 16:22, Kevin Darbyshire-Bryant wrote:
Ok, so the above is done: cobalt merged into mainline cake/master.
cobalt branch rebased/fast-forwarded to the same place, so don't
forget to 'git pull' (or fetch & merge) your own repos.
Patches for LEDE to point at t
On 02/06/16 13:29, Jonathan Morton wrote:
On 2 Jun, 2016, at 14:09, Kevin Darbyshire-Bryant
wrote:
Cake uses the flow dissector API to do flow hashing...including per host flows
for dual/triple isolation. The unfortunate bit is that the qdisc inevitably
gets placed after packets have
On 30/06/16 11:27, Jonathan Morton wrote:
On 30 Jun, 2016, at 12:33, Kevin Darbyshire-Bryant
wrote:
+#ifdef CONFIG_NET_SCH_ESFQ_NFCT
+ enum ip_conntrack_info ctinfo;
+ struct nf_conn *ct = nf_ct_get(skb, &ctinfo);
+#endif
Good find. If this actually works the way we want i
On 30/06/16 20:23, Kevin Darbyshire-Bryant wrote:
On 30/06/16 11:27, Jonathan Morton wrote:
On 30 Jun, 2016, at 12:33, Kevin Darbyshire-Bryant
wrote:
+#ifdef CONFIG_NET_SCH_ESFQ_NFCT
+ enum ip_conntrack_info ctinfo;
+ struct nf_conn *ct = nf_ct_get(skb, &ctinfo);
+#endif
On 01/07/16 09:11, Kevin Darbyshire-Bryant wrote:
I'm beginning to think there's a reason why enhanced sfq which is
where I found that code never made it upstream :-/ It's been/being
an interesting little diversion...and I've modified a kernel module
that so far doe
Hi guys,
Encountering some behaviour that I don't understand. Line is a 40/10
cake limited to 39000/9840. Overheads 12, 'dual-dsthosts' in ingress,
'dual-srcshosts' on engress - limiting the on the WAN line. Take a look
at my ping response graph
http://www.thinkbroadband.com/ping/share/9822
il to replicate? Hmmm, so
far I've used a local flent server...I wonder if RTT is at play here?
Kevin
On 7/16/16 11:35 AM, Kevin Darbyshire-Bryant wrote:
Hi guys,
Encountering some behaviour that I don't understand. Line is a 40/10
cake limited to 39000/9840. Overheads 12, 'dual-
The 'less wrong' overhead figure is 12. The incumbent telco BT who
provide access to the 'last mile' (or the bit from the nearest FTTC
cabinet and the property) use a VLAN tag, adding another 4 bytes to each
frame going over the wire.
The above guesswork based on SIN498 http://www.sinet.bt.c
On 14/09/16 21:06, techic...@gmail.com wrote:
I'm back again, been quite busy so lost track of this. I'm using LEDE
now too.
Is there an easy way to see cake is actually working? A command or
something I can type in just to get clarification?
You can prove that cake is being used as the queu
On 14/09/16 21:48, Sebastian Moeller wrote:
Whilst in this section of the LuCi GUI, I noticed "Which linklayer
adaptation mechanism to use; for testing only", has a "cake" option?
Should this be enabled?
Yes it should be enabled.
This really depends... Tc's stab (size table) method rea
Greetings!
A while back I started on a quest to make cake 'nat' aware as the lack
of host fairness in a typical home router environment was the only thing
that prevented cake from being the ultimate qdisc in my opinion. This
involves dealing with conntrack which on egress is easy (the kernel
right thing, but also allow crazy stuff if need be).
Do you have any idea how expensive this is computationally? I realize that this
is a tad hard to measure as cake will not simply reduce the available bandwidth
when running out of CPU cycles but first will allow the latency to increase.
Best
On 26/09/16 14:28, moeller0 wrote:
Hi Kevin,
This really needs to be tested. As I mentioned the 'ingress' side
of things is harder work because the kernel hasn't filled in the
conntrack pointer for us. There are some remaining concerns over
how reliable our own lookup actually is. The conn
get this error:
Package kmod-sched-cake is missing dependencies for the following
libraries:
nf_conntrack.ko
>From 2d0d549f072379da20be70535c14b40496d42dfb Mon Sep 17 00:00:00 2001
From: Kevin Darbyshire-Bryant
Date: Thu, 30 Jun 2016 16:09:32 +0100
Subject: [PATCH 1/3] kmod-sched-cake:
#x27;namespace.o' failed**
**make[4]: *** [namespace.o] Error 1**
**make[4]: Leaving directory '/home/n0man/Desktop/denat/lib'*
Any help would be appreciated.
Thank you,
Noah Causin
On 9/26/2016 10:32 PM, Kevin Darbyshire-Bryant wrote:
Easy fix. See the added DEPENDS line in
On 28/09/16 00:08, Jonathan Morton wrote:
On 26 Sep, 2016, at 06:20, Kevin Darbyshire-Bryant
wrote:
Another github user 'tegularius' presented some beautifully crafted
code that did the lookups in a much neater way. Originally it too
had an 'ingress' lookup problem.
On 28/09/16 04:06, Jonathan Morton wrote:
On 28 Sep, 2016, at 05:56, Kevin Darbyshire-Bryant
wrote:
Does this need to be another variable/parameter or could it be the
next bit along in the flow type?
I’ve already pushed it to the ‘cobalt’ branch, so you can see how
I’ve done it and start
On 27/09/16 21:40, Noah Causin wrote:
Thank you for all your help.
The de-nat with dual-flow isolation works great. I tested it
simultaneously with two separate virtual machines, one running a Flent
50 flows download test and the other running a Flent 8 flows download
test. Throughput was ev
06, Jonathan Morton wrote:
On 28 Sep, 2016, at 05:56, Kevin Darbyshire-Bryant
wrote:
Does this need to be another variable/parameter or could it be the next bit
along in the flow type?
I’ve already pushed it to the ‘cobalt’ branch, so you can see how I’ve done it
and start testing. I’ve veri
On 28/09/16 07:07, Kevin Darbyshire-Bryant wrote:
Two buglets found:
in sch_cake - the atm/ptm flag options are not passed back to tc
userspace correctly - ptm isn't sent back.
Just fixed that & pushed don't forget to pull :-)
__
On 28/09/16 12:49, Dave Taht wrote:
From a multiple IP perspective, at least on egress through a switch,
you could hash on the mac address instead of the IP...
/me hides
^^^ Yes! Back to your spam trap :-)
___
Cake mailing list
Cake@lists.b
On 04/10/16 08:22, Jonathan Morton wrote:
I’ve just merged the NAT, PTM and Linux-4.8 compatibility stuff into the master
branch of Cake. It’s stable code and a definite improvement.
This frees up the Cobalt branch for more experimentation, such as the rewrite
of triple-isolate that I also
Hi Jonathan,
How amenable are you to changing all 4 BUG_ON instances in cake to WARN_ON?
Linus isn't a complete fan and I'm thinking that producing a stack trace
and trying to carry on is more helpful to a remote accessed, no serial
interface type device than just killing the kernel dead.
Qu
On 05/10/16 16:42, Jonathan Morton wrote:
On 5 Oct, 2016, at 18:24, Kevin Darbyshire-Bryant
wrote:
How amenable are you to changing all 4 BUG_ON instances in cake to
WARN_ON?
Linus isn't a complete fan and I'm thinking that producing a stack
trace and trying to carry on is more
On 05/10/16 16:53, Dave Taht wrote:
I did test this version of cake yesterday, had no major problems, aside from:
1) it seeming not to register drops under some circumstances in the
statistics. (could be flent)
2) switching stuff like this
tc qdisc add dev eth0 root cake bandwidth 700mbit
tc
On 05/10/16 17:38, Dave Taht wrote:
I cannot repeat that result this morning, with either replace or
change.
Out of interest Dave, which branch are you building/testing? The
'master' or 'cobalt'?
___
Cake mailing list
Cake@lists.bufferbloat.net
On 05/10/16 19:53, Jonathan Morton wrote:
I wonder what it was that caused yesterday's issues? I really
must try again when I've more time to get proper access.
I’m having trouble reproducing it here. I know one of my boxes
froze the very first time I loaded it, but it’s been running fine
e
On 07/10/16 14:35, Jonathan Morton wrote:
On 7 Oct, 2016, at 16:27, Kevin Darbyshire-Bryant
wrote:
It's now ok...so far :-)
Okay. I think I’ve found a couple of other things to improve, so stand by…
I'm not sure I can take all this excitemen
Greetings,
Guido Sarducci has very kindly done the work to backport de-natting to
<4.4.0 kernels (commit 70169dba14daa6ef7907af9c1e922ef9f797993a) This
is now merged into cake/master.
For those following the tree, don't forget to pull :-)
JM - I've not yet cherry-picked that into cobalt pending
On 12/10/16 11:21, Dave Taht wrote:
I still defend the idea of the diffserv "squash" option cake once had.
It was essentially RFC compliant, simple to use, and because iptables
was too late on inbound, needed, no matter the layer violation.
Yeah I liked it too, so much I even thought about ha
On 20/12/16 00:10, Dave Taht wrote:
I note that jon just merged cobalt and made the sqm mode (diffserv3)
and triple-isolate the default.
The cobalt branch pre 'diffserv3' merge into master has been in LEDE for
the past 8 days and the post 'diffserv3' merge along with an iproute/tc
tweak is
Forgot to add:
sqm-scripts itself forces 'diffserv4' so you won't see the default of
'diffserv3' sadly, but at least you can override that with the advanced
qdisc options.
On 20/12/16 08:46, Kevin Darbyshire-Bryant wrote:
On 20/12/16 00:10, Dave Taht wrote:
I
Hi All,
I've been out of the loop for a while and just noticed the 'ingress'
mode for cake in the cobalt experimental branch.
Colour me confused on how to use this. My (typical) situation is I've
'eth0' as my WAN port connected to an ISP VDSL2 modem - this is
naturally asymmetric in capacit
Ahh, cheers Jonathan, understand! (and thanks for the really quick reply)
Kevin (much less confused)
On 06/04/17 10:19, Jonathan Morton wrote:
On 6 Apr, 2017, at 12:17, Kevin Darbyshire-Bryant
wrote:
Can I now apply two qdiscs to eth0 directly??? An ingress mode cake and an
egress mode
On 11/04/17 14:59, George Amanakis wrote:
Hi Jonathan,
I have some questions regarding the algorithm to choose a tin to dequeue
from in sch_cake.c:
---8<
int oi, best_tin=0;
s64 best_time = 0xUL;
for(oi=0; oi < q->tin_cnt; oi++) {
Hi All,
It's all gone very quiet in here and I'm pondering the current status of
master & cobalt branches. Is the stuff in cobalt getting closer to
being promoted to master?
Hoping things aren't going stale, 'cos I rather like this combined AQM &
shaper :-)
Cheers,
KDB
Hi All,
This email finds me looking for a volunteer/s to take over the ownership
of the cake qdisc module package in LEDE.
It's not particularly onerous, in essence making sure the package points
at the git commit considered 'stable'.
In theory there's a 'matching' user space patch for 'tc'
On 13/06/2017 23:02, Stephen Hemminger wrote:
> On Tue, 13 Jun 2017 18:41:05 +0100
> Kevin Darbyshire-Bryant wrote:
>
>> Hi All,
>>
>> This email finds me looking for a volunteer/s to take over the ownership
>> of the cake qdisc module package in LEDE.
>&g
On 28/06/17 00:58, Outback Dingo wrote:
Ill take it
Thank you, appreciated.
I can update my patch into LEDE where I drop maintainer to change to
you, or you can generate your own patch to take over up to you.
The PKG_MAINTAINER field does require a real name though.
Cheers,
Kev
On 27/06/17 19:41, Adrian Popescu wrote:
Hello,
I've been reading the code for a while. I'll experiment and send any
useful patches.
The technical docs would have been extremely useful in the process.
The CakeTechnical page is useful, but it lacks descriptions of the
algorithms.
Is cake stil
On 05/09/17 09:01, Sebastian Moeller wrote:
I believe this is used internally so cake can deduce the size of the
automatically added overhead (the linux kernel will add 14 bytes on ethernet
interfaces automatically, which while certainly justifiable are not the ideal
value for an et
On 05/09/17 15:37, Ryan Mounce wrote:
+1
It would also be nice for tc to know whether the overhead has been
explicitly configured and report appropriately. In my case I use cake
on a VLAN sub-interface that happens to have a hard_header_len of 18
after the 802.1q tag, and then use the docsis
I wish this would happen for cake:
https://lists.zx2c4.com/pipermail/wireguard/2017-October/001801.html
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
> On 21 Nov 2017, at 21:59, Dave Taht wrote:
>
>
> You will want to pull and rebase on top of this.
>
> Are there any other patches still lying out of tree worth considering?
Just did a PR for turning max_skblen (or whatever it is) to a u32….since there
*are* super packets out there >64KB.
> On 23 Nov 2017, at 17:07, Dave Taht wrote:
>
> Kevin Darbyshire-Bryant writes:
>>
>> Just did a PR for turning max_skblen (or whatever it is) to a u32….since
>> there *are* super packets out there >64KB.
>
> There are?
There are! Well there were. Fo
> On 25 Nov 2017, at 03:59, Dave Taht wrote:
>
> there is no place in the current code base where these are not both
> true or both false. Thus redundant.
>
> ?
Yes, interesting that. Been there since introduced in 5a6da2ba Add
triple-isolation support. *EXPERIMENTAL*
Have done a PR https
> On 25 Nov 2017, at 15:19, Jonathan Morton wrote:
>
> I think I originally intended to make them individually conditional on the
> src/dest host flags, but that idea evidently got forgotten.
>
> - Jonathan Morton
Ahh, is this
https://github.com/ldir-EDB0/sch_cake/commit/53953e073e26c45ac67
> On 25 Nov 2017, at 16:41, Jonathan Morton wrote:
>
> Not quite. The "dual" enums have more than one bit set, so you have to test
> them for equality.
>
> - Jonathan Morton
Oh dammit, yes they are dual bit flags, rats. good catch. v2 shortly he he
:-)
__
> On 25 Nov 2017, at 16:41, Jonathan Morton wrote:
>
> Not quite. The "dual" enums have more than one bit set, so you have to test
> them for equality.
>
> - Jonathan Morton
Here you go
https://github.com/ldir-EDB0/sch_cake/commit/795db1d1df9f9a400d8c4861eeff59b85994ccfb
- rebased onto c
Ooops, sorry, dodge merge on my part from my work tree back to cobalt. A fix &
PR will be with you shortly…. apologies.
Kevin
> On 25 Nov 2017, at 20:03, George Amanakis wrote:
>
> I think we missed an "allocate_host" in cake_hash(), line ~810:
>
> if (allocate_host) {
> srchost_
https://github.com/dtaht/sch_cake/pull/74
Once again, sorry about the screwup.
> On 25 Nov 2017, at 20:49, Kevin Darbyshire-Bryant
> wrote:
>
> [This sender failed our fraud detection checks and may not be who they appear
> to be. Learn about spoofing at http://aka.ms/Lea
Hi All,
If anyone is brave I’ve just done a commit with the src/dst host allocate stuff
minus the gotos. Not even compile tested! Woke up with it in my head. I’m not
convinced it’s really cleaner, absolutely no idea if it’s faster. But it’s
here with all sorts of major caveats :-)
https://g
> On 26 Nov 2017, at 10:00, Jonathan Morton wrote:
>
> On a purely theoretical basis, it probably isn't as fast, because now the
> 'found' condition has to be tested multiple times on the fast and slow paths
> alike. Only if the compiler is smart enough to transform it back the way it
> was
Have to say, my perception is that I’ve a small cpu usage improvement for my
use case with these changes. Then I would expect that ‘cos I use
‘dual-srchost’ on egress and ‘dual-dsthost’ on ingress, so I’m saving running
the dst/src host allocation code on egress/ingress respectively.
Of cours
> On 26 Nov 2017, at 18:22, Dave Taht wrote:
>
> Toke Høiland-Jørgensen writes:
>
>> gamana...@gmail.com writes:
>>
>>> Just finished building, setting both sch_cake and nf_conntrack as
>>> integral succeeds. Setting nf_conntrack as module fails with sch_cake
>>> as integral (makes sense).
>
In the nicest possible way… what on earth is going on with the cake source tree
of late? Many ‘cascaded’ merges make things impossible to read and stuff
appears to be getting lost as well. e.g. the recent change "Switch ingress
failsafe to 2/3 instead of 1/4 bandwidth.” has now appeared twice,
> On 28 Nov 2017, at 18:48, Dave Taht wrote:
>
>
>
> It sounds like your git-foo is stronger than ours! I'm not even trying
> to get head to work, tho my intent would be to promote cobalt to it.
git checkout master
git pull (does the equivalent of git fetch origin; git merge origin/master)
> On 7 Dec 2017, at 08:21, Jonathan Morton wrote:
>
> Okay, I found that the parameters used were suspicious and didn't prevent
> Cake from dropping packets. I've pushed a tc-adv update to fix that, so you
> should try that again.
>
> Other RTT keywords are unaffected.
Can’t find the tweak
> On 7 Dec 2017, at 02:19, Jonathan Morton wrote:
>
> > It would be nice to have a test showing blue being useful.
>
> To do that, you would need to have a saturating unresponsive load, such as a
> UDP flood, which drives Cake's queue to the memory limit. Even then, I
> suspect you wouldn't
This didn’t seem to generate any response so I’ll have a go :-)
> On 6 Dec 2017, at 00:06, Dave Taht wrote:
>
> as 1400+ bytes on the parisc stack, is a bit much. That said, I don't
> see much possibility for shrinkage overall.
How much over do you happen to know? I see a number of options (6 o
> On 17 Dec 2017, at 15:23, Sebastian Moeller wrote:
>
> Hi Mark,
>
>> On Dec 17, 2017, at 11:45, Mark Captur wrote:
>>
>> My setup is as follows
>>
>> vdsl2 modem doing pppoe itself and nat to 10.x.x.x -> lede master eth0.2
>> (wan static ip in modem's DMZ) eth0.1 (lan) doing nat to 192.1
> On 22 Dec 2017, at 06:38, Jonathan Morton wrote:
>
>> On 21 Dec, 2017, at 2:54 am, Andy Furniss wrote:
>>
>> refactor cake_advance_shaper and ack_filter
>>
>> cake_advance_shaper now returns a modified len argument to
>> reflect cake_overhead.
>> skb_ack_filter variable replaced wi
> On 22 Dec 2017, at 10:00, Jonathan Morton wrote:
>
> Git seems to regularly get confused when similar code changes occur in
> parallel in different branches. In this case, I had the original version of
> ingress mode while the public tree had the reconstructed version - almost
> identical
> On 23 Dec 2017, at 21:03, Sebastian Moeller wrote:
>
> Hi All,
>
> just had a look for hard_header_len in the linux kernel:
> linux/include/linux/netdevice.h:
> * @hard_header_len: Maximum hardware header length.
> * @min_header_len: Minimum hardware header length
>
> this seems
> On 24 Dec 2017, at 10:39, Jonathan Morton wrote:
>
> If you combine the 'raw' keyword with an overhead spec, that disables the
> hard_header_len compensation.
>
> - Jonathan Morton
Indeed. I think all I’m proving is ‘make something idiot proof…..they’ll only
go and improve the idiot’… i.
Hi All,
> On 7 Mar 2018, at 08:50, Toke Høiland-Jørgensen wrote:
>
> Jonathan Morton writes:
>
>>> On 6 Mar, 2018, at 11:06 pm, Toke Høiland-Jørgensen wrote:
>>>
>>> ...on the iproute2 side the only
>>> thing missing before we can attempt an upstream submission is an update
>>> of the man
> On 7 Mar 2018, at 10:31, Toke Høiland-Jørgensen wrote:
>
>>
>
> Please don't put something different into LEDE than what we're working
> on upstreaming. It is difficult enough to keep track of the different
> versions as they are. The tc-adv repo is already rebased on the upstream
> iproute
There were some useful stats column re-alignment changes as well, wonder if you
got those?
> On 7 Mar 2018, at 10:36, Toke Høiland-Jørgensen wrote:
>
> Toke Høiland-Jørgensen writes:
>
>> Kevin Darbyshire-Bryant writes:
>>
>>> Hi All,
>>>
&g
72
memory used: 78592b of 4Mb
capacity estimate: 19900Kbit
min/max transport layer size:4537916 / 4537972
min/max overhead-adjusted size: 4538000 / 4537972
average transport hdr offset:4538072
I’m pondering if it’s an endian issue?
> On 7 Mar 2018, at 11:28, Toke Høiland-Jørgensen wr
> On 7 Mar 2018, at 12:59, Toke Høiland-Jørgensen wrote:
>
>
>> qdisc cake 8004: root refcnt 4486780 bandwidth 19900Kbit diffserv3
>> dual-srchost nat rtt 100.0ms ptm overhead 4502152
>> Sent 42615751 bytes 4491092 pkt (dropped 4491108, overlimits 4491124
>> requeues 4491152)
>> backlog 0b 4
> On 7 Mar 2018, at 18:27, Kevin Darbyshire-Bryant
> wrote:
>
>
>
>> On 7 Mar 2018, at 12:59, Toke Høiland-Jørgensen wrote:
>>
>>
>>> qdisc cake 8004: root refcnt 4486780 bandwidth 19900Kbit diffserv3
>>> dual-srchost nat rtt 100.0ms p
> On 8 Mar 2018, at 00:49, Jonathan Morton wrote:
>
>> On 7 Mar, 2018, at 11:34 pm, Toke Høiland-Jørgensen wrote:
>>
>> Ah, totally missed that those were wrong as well. The values for
>> dropped, overlimits and requeues are not printed by the cake-specific
>> code at all, so there is somethi
> On 8 Mar 2018, at 07:59, Kevin Darbyshire-Bryant
> wrote:
>
> Definitely dubious and I’m no longer convinced it’s a cake only issue.
> Looked at my AP which is running an older version of openwrt, so older cake,
> older kernel etc etc and all qdiscs are returning o
> On 8 Mar 2018, at 10:57, Toke Høiland-Jørgensen wrote:
>
> Kevin Darbyshire-Bryant writes:
>
>> Archer c7 v2. master branch of openwrt
>
> Ah, great; I actually have one of those sitting on my desk that I could
> potentially reflash without breaking anything
> On 8 Mar 2018, at 11:09, Kevin Darbyshire-Bryant
> wrote:
>
>
>
>> On 8 Mar 2018, at 10:57, Toke Høiland-Jørgensen wrote:
>>
>> Kevin Darbyshire-Bryant writes:
>>
>>> Archer c7 v2. master branch of openwrt
>>
>> Ah, great;
> On 8 Mar 2018, at 11:21, Toke Høiland-Jørgensen wrote:
>
>>
>> Oh and curiously the bad values go away if you ask for json output
>> it’s much better. Which rather points at a ‘feature’ of the
>> ‘print_string’ behaviour.
>
> Right. Well, the print_* functions are behind several levels of
Signed-off-by: Kevin Darbyshire-Bryant
---
tc/tc_qdisc.c | 3 ++-
tc/tc_util.c | 24
2 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/tc/tc_qdisc.c b/tc/tc_qdisc.c
index 70279b9d..3ec74a1c 100644
--- a/tc/tc_qdisc.c
+++ b/tc/tc_qdisc.c
@@ -20,6 +20,7
Signed-off-by: Kevin Darbyshire-Bryant
---
tc/q_cake.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/tc/q_cake.c b/tc/q_cake.c
index 44cadb63..f888bd2a 100644
--- a/tc/q_cake.c
+++ b/tc/q_cake.c
@@ -47,6 +47,7 @@
#include
#include
#include
+#include
Here's 2 patches that fix (for me!) tc's strange output on a MIPS platform.
[PATCH 1/2] cake: print_uint format fixes
[PATCH 2/2] tc print_uint format fixes
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
1 - 100 of 236 matches
Mail list logo
