moeller0 writes:
> So, my take on this is that we want to be able to re-map DSCP to zero. On
> ingress if we do not trust our upstream to do the right thing on egress if we
> do
> not want to leak internal information to our upstream. As far as I can tell
> DSCP
> is supposed to be domain speci
Jonathan Morton writes:
> It would be nice if LuCI could infer information about the likely
> overheads from the rest of the configuration, and apply (or suggest &
> default) the correct keywords in sqm-scripts. That would make the
> feature much more widely used.
We can probably do this for the
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 be upon us. Interest has been
> expressed in http://www.buff
Neil Shepperd writes:
> I think I have now accumulated enough spam/nonspam classified emails
> to make a statistically signification observation: it seems like all
> emails classified as spam from these lists were send from ipv6:
>
> SPF: PASS with IP 2600:3c03:0:0:f03c:91ff:fe61:86ce
>
> All e
"Jason A. Donenfeld" writes:
> Hi all,
>
> On Fri, Sep 30, 2016 at 9:18 PM, Dave Taht wrote:
>> All: I've always dreamed of a vpn that could fq and - when it was
>> bottlenecking on cpu - throw away packets intelligently. Wireguard,
>> which is what jason & co are working on, is a really simple,
Dave Taht writes:
> My thought - given that at least on some platforms - encrypting 1000
> packets at a time is a bad idea - would be something regulating the
> amount of data being crypted at a time, an equivalent to byte queue
> limits - BQL - BCL? byte crypto limits - to keep no more than, say
Dave Taht writes:
> On Sat, Oct 1, 2016 at 8:51 AM, Toke Høiland-Jørgensen wrote:
>> Dave Taht writes:
>>
>>> My thought - given that at least on some platforms - encrypting 1000
>>> packets at a time is a bad idea - would be something regulating the
>>&
"Jason A. Donenfeld" writes:
> Thanks a lot for your responses. This is steering me in the right direction (I
> hope!). Responses are inline below.
>
> Regards,
> Jason
>
> On Sat, Oct 1, 2016 at 1:51 PM, Toke Høiland-Jørgensen wrote:
>> Looking at your qu
"Jason A. Donenfeld" writes:
> Hey Toke,
>
> On Sun, Oct 2, 2016 at 1:40 AM, Toke Høiland-Jørgensen wrote:
>> I assumed that there probably was, but was not sure where. Thanks for
>> clearing this up. I'll take a step back and try to describe this on the
"Jason A. Donenfeld" writes:
> On Sun, Oct 2, 2016 at 1:31 PM, Toke Høiland-Jørgensen wrote:
>> You don't need a timer. You already have a signal for when more queue
>> space is available in the encryption step: When a packet finishes
>> encryption. All you
The airtime fairness patch for ath9k has been accepted into the mainline
Linux kernel, and is queued to be merged for 4.11 (i.e. the next merge
window after the current 4.10 cycle completes).
The patch has also been accepted into LEDE and is currently in Felix'
staging tree at
https://git.lede-pro
Valent Turkovic writes:
> Please send just a short notification as soon as Lede with airfairness
> has been released, I have really good real world location that can
> test how effective it works...
It should be in the nightly LEDE builds by now :)
-Toke
Pete Heist writes:
> Hi, I’ve posted some Flent results and analysis for point-to-point Wi-Fi
> using LEDE on OM2P-HS (ath9k):
>
> http://www.drhleny.cz/bufferbloat/wifi_bufferbloat.html
Oh my, this is quite a lot of tests. Nice :)
Few general points on running tests:
- Yeah, as you note Fle
"Klatsky, Carl" writes:
> Finally had some time to get to this request. I downloaded the current git
> version of Flent and was able to launch the flent-gui on Windows. I had some
> old
> test *.flent.gz results files which loaded just fine. I tried to open the test
> files that were linked from
Stephen Hemminger writes:
> On Tue, 20 Dec 2016 11:02:44 -0800
> Dave Taht wrote:
>
>> Toke has been busy adding new features to the flent network test tool.
>> I consider it *almost* stable enough for a new release. Some of the
>> development has been focused on making the flent-gui much faster
Stephen Hemminger writes:
> On Tue, 31 Jan 2017 17:35:40 +0100
> Toke Høiland-Jørgensen wrote:
>
>> Stephen Hemminger writes:
>>
>> > On Tue, 20 Dec 2016 11:02:44 -0800
>> > Dave Taht wrote:
>> >
>> > Has anyone automated or orch
Pete Heist writes:
> On Jan 30, 2017, at 10:44 PM, Toke Høiland-Jørgensen wrote:
>
> Oh my, this is quite a lot of tests. Nice :)
>
> It’s also a thumbs up for the ath9k driver changes that nothing went
> wrong during the testing. It takes about 15 hours for a full run an
Aaron Wood writes:
> - Yeah, as you note Flent has a batch facility. Did you not use this
>simply because you couldn't find it, or was there some other reason?
>Would love some feedback on what I can do to make that more useful to
>people... While I have no doubt that your 'flenter.p
Pete Heist writes:
> On Feb 1, 2017, at 3:48 PM, Toke Høiland-Jørgensen wrote:
>
> Pete Heist writes:
>
> Few general points on running tests:
>
> - Yeah, as you note Flent has a batch facility. Did you not use this
> simply because you couldn't find it, o
Pete Heist writes:
> Yeah, I have recently begun learning Go myself, and like it too. Apart
> from the fact that it produces these huge statically linked binaries,
> and requires glibc, so you can't run it on embedded systems (such as
> LEDE).
>
> If I were to integrate code that actually sh
Pete Heist writes:
>> On Feb 8, 2017, at 5:11 PM, Toke Høiland-Jørgensen wrote:
>>>
>>> That reminds me, is there any way to disable fq-codel in the ath9k
>>> driver, and revert to being able to use the qdisc layer without
>>> limiting? Then I could
Pete Heist writes:
> On Feb 9, 2017, at 2:51 PM, Toke Høiland-Jørgensen wrote:
>
> Also, could the queue management code be abstracted into a separate
> module, so it can be replaced, like a qdisc? I don’t know if the
> disparity between hardware makes this too difficult or
Pete Heist writes:
> On Feb 16, 2017, at 10:03 PM, Sebastian Moeller wrote:
>
> On Feb 16, 2017, at 18:19, Jonathan Morton wrote:
>
> In a sense if there are thresholds for permissible VO/VI traffic fractions
> below which the AP will not escalate its own priority this will come close to
>
Jonathan Morton writes:
>> On 22 Feb, 2017, at 13:12, Pete Heist wrote:
>>
>> Ok, but for what it’s worth, so far I’m not seeing this confer any benefit as
>> far as latency is concerned. I will make full results available later, but
>> for
>> now, here are two plots for the rrul test
>
> The
leetminiwheat writes:
> Apologies I haven't had time to follow recent developments but are there
> any recent bufferbloat/CAKE related news/recommendations for the APU2
> platform? Specifically the APU2C (previous was marvell I believe)
>
> Hardware:
> APU2C4 (AMD x86_64 | 4GB | 3x i210-AT)
> W
Pete Heist writes:
> Suppose there is a cooperative ISP that has some members who access the
> network through a single device (like a router with NAT), while others use
> multiple devices and leave routing to the ISPs routers. (No need to suppose,
> actually.)
>
> There’s fairness at the IP a
Pete Heist writes:
> On Apr 6, 2017, at 11:33 AM, Toke Høiland-Jørgensen wrote:
>
> Once upon a time I implemented something like this; it was basically a
> PHP script that would generate an HTB bucket (with sfq as leaf qdisc;
> this was pre-fq_codel) per subscriber ID and u
Pete Heist writes:
> On Apr 6, 2017, at 12:50 PM, Toke Høiland-Jørgensen wrote:
>
> Pete Heist writes:
>
> The fq_codel qdisc does have support for arbitrary tc filters to replace
> the default hashing, BTW. If you don't need the cake shaper, that might
> be
Pete Heist writes:
> On Apr 6, 2017, at 2:14 PM, Toke Høiland-Jørgensen wrote:
>
> Pete Heist writes:
>
> but I’m still a little confused. Is fq_codel actually a classful
> qdisc?
>
> Yup. The hash buckets are the classes, basically. You can get per-flow
>
Jon Pike writes:
> Thought this might be a good place to ask a question or two abt the
> wifi fast stuff... while Toke's listening.
>
> 1. What's the status of make wifi fast on the ath10k now, or did it
> make it there yet?
Well, the queue rework is in there, but only enabled for certain
hardwa
writes:
> Just a follow-up from the great support I got here. I am now running ER-X
> with cake with the precompiled binaries from Nils. I need to do some tuning
> and get it properly into the lab. Currently I'm dogfooding it at home.
>
> Any other suggestions in order to make the topping of
writes:
>> Fra: Sebastian Moeller
>
>> .. snip
>> One problem with the unelastic load is that as far as I can tell no flow on
>> the open internet is
>> allows/assumed to behave like that (isn’t the default tcp-friendly, and
>> inelastic DOS traffic is
>> essentially out-lawed?)
>
> You ar
On 5 May 2017 16:30:38 GMT+02:00, erik.tarald...@telenor.com wrote:
>
>> Den 5. mai 2017 kl. 15.59 skrev Toke Høiland-Jørgensen
>:
>>
>> How are you measuring latency in this case?
>
>I use nuttcp with the option -o. It uses system time on the two peers.
>Make
Jonathan Morton writes:
> I think "mostly true but incomplete" is the best way to describe the
> current pages.
Patches welcome :)
https://github.com/tohojo/bufferbloat-net
-Toke
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbl
Dave Taht writes:
> ---
> net/sched/Kconfig | 11 +++
> net/sched/Makefile | 1 +
> 2 files changed, 12 insertions(+)
>
> diff --git a/net/sched/Kconfig b/net/sched/Kconfig
> index c03d86a..3ea22e5 100644
> --- a/net/sched/Kconfig
> +++ b/net/sched/Kconfig
> @@ -284,6 +284,17 @@ config
has been
>> running a few years behind mainline Linux. A stable version has been
>> generally available on lede-17.01 and later.
>>
>> sch_cake replaces a combination of iptables, tc filter, htb and fq_codel in
>> the sqm-scripts, with sane
Dave Taht writes:
> Pete Heist writes:
>
>> On Nov 23, 2017, at 10:44 AM, Jonathan Morton
>> wrote:
>>
>> This is most likely an interaction of the AQM with Linux' scheduling
>> latency.
>>
>> At the 'lan' setting, the time comstants are similar in magnitude to the
>>
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).
So this probably needs either a Kconfig dependency or an ifdef?
-Toke
_
On 26 November 2017 19:22:35 CET, 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
&g
Pete Heist writes:
> * I wonder if the UDP flood tests really work at 900mbit:
Did you set the UDP bandwidth? --test-parameter udp_bandwidth=1000M for
instance
-Toke
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listin
> I would not be surprised to find out that this result was also due to
> lack of CPU, since there’s a steady degradation in Cake’s performance
> above 200mbit. Next time I’ll try 8/8 flows in addition.
If you add --test-parameter cpu_stats_hosts=localhost you will also get
a graph of CPU usage wh
Pete Heist writes:
>> On Nov 27, 2017, at 9:37 PM, Toke Høiland-Jørgensen wrote:
>>
>> If you add --test-parameter cpu_stats_hosts=localhost you will also get
>> a graph of CPU usage which while somewhat rudimentary should at least
>> make it possible to see
Dave Taht writes:
> A flag day here is feasible. I will fiddle along the lines you
> describe.
FWIW I don't think the history is that bad. Sure, there are a bunch of
merge commits, but picking out the real ones is not that difficult
(unless you are using the github web interface, I guess, but th
Georgios Amanakis writes:
> I am troubled by the number of data points flent reports for some pings and
> uploads in this setup. A typical ack-filter result, similar to rrul2 I
> posted before, looks like this:
> Summary of rrul test run 'rrul_cakeeth_ds3_900mbit_45mbit_ack' (at
> 2017-11-29 14:3
> (That was also informative for me about how netperf decides when to
> emit a data point…)
In that case I can add that the stated reason for this way of doing
things is performance (i.e., emitting data points should not interfere
with transfer performance). This is mostly an issue on systems wher
Georgios Amanakis writes:
> @Pete @Toke just saw your responses. Thank you very much for the
> explanation. I will give irtt and flent-git a try, and maybe build an
> aur package for archlinux.
There's already an AUR package for flent-git; haven't gotten around to
making one for irtt, but am fin
Pete Heist writes:
>> On Nov 29, 2017, at 4:44 PM, Toke Høiland-Jørgensen wrote:
>>
>>> (That was also informative for me about how netperf decides when to
>>> emit a data point…)
>>
>> In that case I can add that the stated reason for this
Georgios Amanakis writes:
> Results with irtt/flent-git. Same setup as before:
Looks like that is still using netperf for the UDP measurements. Flent
does some sanity checks on irtt before using it, which may be failing.
Running flent with -v should give some hints...
-Toke
dpr...@reed.com writes:
> BTW, one annoying thing about flent is that netperf is not available
> in fedora, rhel, centos as a package. So I have to install it and it
> doesn't just plug in smoothly. That's just my convenience issue. I
> don't use netperf myself on any of my systems. iperf and ipe
Georgios Amanakis writes:
> I had to run flent with "-s 0.61" in order to avoid errors with fping dying
> prematurely.
When did fping die, and did you still get results? There's a watchdog
timer to keep it from running too long, but maybe that is a bit too
aggressive?
-Toke
Georgios Amanakis writes:
> I still got results but did not trust them.
> The error occurred at the end of the run.
>
> ===8<===
> NetperfDemoRunner TCP upload CS5 finished
> NetperfDemoRunner TCP upload EF finished
> TimerRunner Watchdog [Ping (ms) ICMP] finished
Yeah, the watch
Georgios Amanakis writes:
> To correct myself, fping did not die prematurely, it was getting no
> responses from the remote host because its p parameter was too short at
> default for an RTT of 600ms. After looking at the source, I realized that
> it is affected but the s parameter of flent, and
Georgios Amanakis writes:
> I don't really know. When I ran "ping 10.10.0.1" it just worked. fping
> -p250 didn't.
What about ping -i0.2?
-Toke
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
the full number of tins.
Signed-off-by: Toke Høiland-Jørgensen
---
This patch is against the for_upstream_4.16 branch. It compiles, but is
otherwise completely untested. No idea if it will fix the build bot
error from the upstream submission, but couldn't think of any other
obvious way to
On 26 December 2017 17:28:39 CET, Dave Taht wrote:
>The puzzling thing about the reported error for this function is that
>the static analysis checker is complaining about 1400+ bytes being
>used *on the stack* (in gnet_stats_copy-app?) for the pa-risc
>architecture, and that arch, only, which I
This popped up in my Google Scholar notifications:
https://atlas.informatik.uni-tuebingen.de/~menth/papers/Menth18b.pdf
Basically, they are proposing to permit a queue to accumulate a larger
deficit while empty to allow light users to achieve the same throughput
as heavy users (users being an end
the full number of tins.
Signed-off-by: Toke Høiland-Jørgensen
---
v2:
- If we want to be able to extend the tc_cake_tin_stats at a later date
(and if we don't the 'version' field is sort of meaningless), its size
need to be included somewhere so userspace can skip over unkno
Jonathan Morton writes:
>> On 27 Jan, 2018, at 3:05 pm, Toke Høiland-Jørgensen wrote:
>>
>> This splits out the tin stats from tc_cake_xstats, which seems like the
>> least intrusive way of decreasing the size of the stats structure. This
>> way, we can send onl
Høiland-Jørgensen
---
tc/q_cake.c | 103 ++--
1 file changed, 51 insertions(+), 52 deletions(-)
diff --git a/tc/q_cake.c b/tc/q_cake.c
index 6987c4d..3ddc13c 100644
--- a/tc/q_cake.c
+++ b/tc/q_cake.c
@@ -555,6 +555,11 @@ static int
the full number of tins.
Signed-off-by: Toke Høiland-Jørgensen
---
Updated in v3:
- Keep the version field in place in the xstats structure, and set it to
a value higher than 0xFF, which will make old versions of tc ignore
it. This means old versions of tc simply won't print stati
Sebastian Moeller writes:
> Dear All,
>
> I am a bit confused now which tc repository is the one to track.
>
> I believe Jonathan made changes to https://github.com/dtaht/tc-adv
>
> while https://github.com/dtaht/iproute2-cake-next seems overall more recent
> (modulo Jonathan's changes)
>
> So
Jonathan Morton writes:
>> On 11 Feb, 2018, at 7:26 pm, Toke Høiland-Jørgensen wrote:
>>
>> This updates tc to understand the updated cake xstats structure (which
>> splits out the tin stats in a separate structure the length of which is
>> included in the
Toke Høiland-Jørgensen writes:
> Jonathan Morton writes:
>
>>> On 11 Feb, 2018, at 7:26 pm, Toke Høiland-Jørgensen wrote:
>>>
>>> This updates tc to understand the updated cake xstats structure (which
>>> splits out the tin stats in a separate struct
Jonathan Morton writes:
>> On 1 Mar, 2018, at 1:06 pm, Sebastian Moeller wrote:
>>
>> BTW, my testing so far with the latest tc-adv did not result in any crashes,
>> but I also did not research whether the overhead account behaves like
>> expected...
>
> I've just added the relevant stats out
Stephen Hemminger writes:
> On Sun, 11 Feb 2018 18:26:18 +0100
> Toke Høiland-Jørgensen wrote:
>
>> This updates tc to understand the updated cake xstats structure (which
>> splits out the tin stats in a separate structure the length of which is
>> included in the con
Toke Høiland-Jørgensen writes:
> Stephen Hemminger writes:
>
>> On Sun, 11 Feb 2018 18:26:18 +0100
>> Toke Høiland-Jørgensen wrote:
>>
>>> This updates tc to understand the updated cake xstats structure (which
>>> splits out the tin stats in a
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 page, as far as I can tell. Any volunteers to do
Kevin Darbyshire-Bryant writes:
> 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:
>>>>
>>>> ...o
Toke Høiland-Jørgensen writes:
> Kevin Darbyshire-Bryant writes:
>
>> Hi All,
>>
>>
>>
>>> On 7 Mar 2018, at 08:50, Toke Høiland-Jørgensen wrote:
>>>
>>> Jonathan Morton writes:
>>>
>>>>> On 6 Mar, 2018, at
Kevin Darbyshire-Bryant writes:
> There were some useful stats column re-alignment changes as well,
> wonder if you got those?
Probably not, as that code is not longer directly diff'able,
unfortunately... The json-related changes were fairly intrusive...
Eyeballing the diff, however, I *think*
Kevin Darbyshire-Bryant writes:
>> 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 diff
Kevin Darbyshire-Bryant writes:
> I don’t the column alignment can be correct because the print lines don’t
> include a leading space, so columns can run into each other.
>
> fprintf(f, "%12u", tst->unresponse_flows);
> v
> fprintf(f, " %12u", tst->unresponse_flows);
>
> The header lines are pro
Sebastian Moeller writes:
>> diff --git a/tc/q_cake.c b/tc/q_cake.c
>> index e21552e8..95301b41 100644
>> --- a/tc/q_cake.c
>> +++ b/tc/q_cake.c
>> @@ -243,12 +243,22 @@ static int cake_parse_opt(struct qdisc_util *qu, int
>> argc, char **argv,
>>/* Typical VDSL2 framing schemes,
Dave Taht writes:
> So it sounds like all the individual pieces are sync'd again?
>
> 4.16-rc4 is out, so there are several weeks left to make the net-next
> window. I note that I don't feel strongly (never had) that I should be
> the one to make the net-next submission, just so long as it now ge
Kevin Darbyshire-Bryant writes:
>> 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 b
Kevin Darbyshire-Bryant writes:
>> 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 a
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 too important.
In the meantime; do you get the same weird output on the
dropped/overlimit/requeues field
Kevin Darbyshire-Bryant writes:
>> 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:
>>>
>>>&
Dave Taht writes:
> And while I'm breaking things, the link_ms field is entirely unused in
>
> struct tc_cake_traffic_stats {
> __u32 packets;
> __u32 link_ms;
> __u64 bytes;
> };
what was that field supposed to contain?
-Toke
Dave Taht writes:
> While it seems unlikely we'll get to shaping past 40Gbit any time
> soon, perhaps changing the API to 64 bits to specify bandwidth will
> avoid problems in 2024, or with (one day) offloaded hardware.
Might as well. There is not really much of a performance reason to keep
this
Thank you for the patch! :)
> 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 @
Kevin Darbyshire-Bryant writes:
> Signed-off-by: Kevin Darbyshire-Bryant
> ---
> tc/tc_qdisc.c | 3 ++-
> tc/tc_util.c | 24
> 2 files changed, 14 insertions(+), 13 deletions(-)
Care to submit this to upstream iproute2? Amending the commit message
with an explanation
Kevin Darbyshire-Bryant writes:
>> On 11 Mar 2018, at 20:50, Toke Høiland-Jørgensen wrote:
>>
>> Kevin Darbyshire-Bryant writes:
>>
>>> Signed-off-by: Kevin Darbyshire-Bryant
>>> ---
>>> tc/tc_qdisc.c | 3 ++-
>>> tc/tc_u
Kevin Darbyshire-Bryant writes:
>> On 11 Mar 2018, at 23:34, Stephen Hemminger
>> wrote:
>>
>> On Sun, 11 Mar 2018 22:10:51 +
>> Kevin Darbyshire-Bryant wrote:
>>
>>> negative?
>>>
>>> Tried it, and you’d sort of guess wrong. I’ll write it up tomorrow
>>> ‘properly’ but ‘int’ is int len
Stephen Hemminger writes:
>> > Using the ‘PRId64’ macro won’t work because print_int is using ‘int’
>> > type internally whereas print_uint uses ‘uint64_t’ internally. So the
>> > format string has to have knowledge of the internal format, *but*
>> > there’s no clue of the difference in internal
Kevin Darbyshire-Bryant writes:
>> On 12 Mar 2018, at 15:11, Stephen Hemminger
>> wrote:
>>
>> On Mon, 12 Mar 2018 10:56:09 +0100
>> Toke Høiland-Jørgensen wrote:
>>>
>>> Stephen, would you accept patches to fix the API (to add
>>&
George Amanakis writes:
> It seems the change was introduced here:
> https://patchwork.kernel.org/patch/9671147/
>
> I drafted the following very simplistic patch, could somebody take a
> look at it?
LGTM. We may want to actually use the extack feature at some point, but
we're not really returni
Toke Høiland-Jørgensen writes:
> George Amanakis writes:
>
>> It seems the change was introduced here:
>> https://patchwork.kernel.org/patch/9671147/
>>
>> I drafted the following very simplistic patch, could somebody take a
>> look at it?
>
> LG
Georgios Amanakis writes:
> #if LINUX_VERSION_CODE < KERNEL_VERSION(4, 12, 0)
> err = nla_parse_nested(tb, TCA_CAKE_MAX, opt, cake_policy);
> -#else
> +#elif LINUX_VERSION_CODE < KERNEL_VERSION(4, 16, 0)
> err = nla_parse_nested(tb, TCA_CAKE_MAX, opt, cake_policy, NULL);
> +#else
> +
Pushed to git; thanks! :)
-Toke
George Amanakis writes:
> From: gamanakis
>
> Signed-off-by: George Amanakis
> ---
> sch_cake.c | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/sch_cake.c b/sch_cake.c
> index 9f2acb5..22197e0 100644
> --- a/sch_ca
Dave Taht writes:
> fprintf(f, " pkts");
> FOR_EACH_TIN(stnc, tst, i)
> - fprintf(f, " %12u", tst->sent.packets);
> + fprintf(f, " %12llu", tst->sent.packets);
> fprintf(f, "\n");
Presumably this can potentially break column alignment? Not sure that
Dave Taht writes:
> the preceding space handles column alignment. the %12 is probably
> going to be misleading.
The space separates columns, the %12 aligns them. So it will break
alignment. But as I said, mostly a cosmetic issue, so probably not
something we should spend a lot of time on fixing.
Kevin Darbyshire-Bryant via Cake writes:
> From: Kevin Darbyshire-Bryant
> Subject: bufferbloat still misunderstood & ignored
> To: Cake List
> Date: Wed, 28 Mar 2018 15:46:47 +
>
> http://forums.thinkbroadband.com/talktalk/t/4587923-sensible-discussion-with-talktalk-about-bufferbloat.html
Bret Towe writes:
> for anyone seeing a compile error like the below on Arch Linux
>
> CC [M] /root/sch_cake/sch_cake.o
> In file included from ./include/linux/list.h:9:0,
> from ./include/linux/module.h:9,
> from /root/sch_cake/sch_cake.c:42:
> ./include/linu
Jonathan Morton writes:
>> On 29 Mar, 2018, at 1:30 am, Bret Towe wrote:
>>
>> ./include/linux/kernel.h:6:10: fatal error: stdarg.h: No such file or
>> directory
>
> I've started seeing the same error on my PowerPC box, running Gentoo.
> It seemed specific to that machine, but the GCC version
Jonathan Morton writes:
>> On 30 Mar, 2018, at 11:05 am, Pete Heist wrote:
>>
>> So this mapping from member (subscriber) to their MACs or IPs would need to
>> be configurable somewhere
>
> Yes, I assumed something like that would be required to assign the
> correct tier of service (or BRAS ra
Jonathan Morton writes:
>> On 11 Apr, 2018, at 6:24 pm, Toke Høiland-Jørgensen wrote:
>>
>> So, um, did we cram so many features into Cake that it no longer uses
>> less CPU? Can anyone confirm these results?
>
> To be sure about this, it seems wise to configure
Pete Heist writes:
> For what it’s worth, that’s what I also saw testing Cake on the APU2
> late last year, and the ER-X platform earlier. I actually never knew
> that Cake used less CPU at some point. Sorry for no supporting
> detail... :)
Anecdotal supporting evidence is fine. Just needed a sa
Jonathan Morton writes:
>> On 11 Apr, 2018, at 8:15 pm, Toke Høiland-Jørgensen wrote:
>>
>> Also would be nice to get a measure of the smoothness of the
>> shaper; will see if I can't extract that from a pcap file or
>> something
>
> I remember using tc
Jonas Mårtensson writes:
> On Wed, Apr 11, 2018 at 7:15 PM, Toke Høiland-Jørgensen
> wrote:
>
>> Jonathan Morton writes:
>>
>> >> On 11 Apr, 2018, at 6:24 pm, Toke Høiland-Jørgensen
>> wrote:
>> >>
>> >> So, um, did we cram so man
1 - 100 of 683 matches
Mail list logo
