On Mon, Dec 4, 2017 at 1:02 AM, Pete Heist wrote:
>
> On Dec 4, 2017, at 4:29 AM, Dave Taht wrote:
>
>
> *** Round 5 Plans
>
> * If I do another high RTT test, make rtt 1000ms default and try even higher
>
> * From Dave: tcp bbr, cdg, reno? dctcp would be weirdly interesting.
>
> * From Dave: slo
Given some of the results thus far at various RTTs, and at higher
loads, like the ginormous one georgios just ran, I thought it might be
useful to run a battery of tests with blue disabled.
I haven't gone to the trouble of creating a formal branch - tho if I
did, I'd call it rhodium, as rhodium de
Jonathan Morton writes:
> I might try to implement a dynamic target adjustment later today.
The loss of throughput here compared to non-ingress mode is
a blocker for mainlining and for that matter, wedging this into lede.
Has it always deteriorated this way?
>
> - Jonathan Morton
>
>
> ___
As a reminder, noticeable loss of throughput occurs only when there are a
lot of concurrent flows (>16, on my connection).
To my knowledge and testing, ingress mode has been behaving like this from
the beginning.
On Dec 5, 2017 4:15 PM, "Dave Taht" wrote:
> Jonathan Morton writes:
>
> > I migh
The attached patch attempts to deprioritize bulk ack flows in cake.
Once we start accumulating enough acks to filter out, and we start
filtering them out, the "sparse flow optimization" in cake will
start prioritizing the shorter queues. This patch attempts to stop
that, which should give more tim
Great! I am repeating the 200mbit/10mbit 32/8 flows, RTT 20ms scenario with
the patch.
On Dec 5, 2017 2:32 PM, "Dave Taht" wrote:
> Given some of the results thus far at various RTTs, and at higher
> loads, like the ginormous one georgios just ran, I thought it might be
> useful to run a battery
As a reminder, noticeable loss of throughput occurs only when there are
a lot of concurrent flows (>16, on my connection).
To my knowledge and testing, ingress mode has been behaving like this
from the beginning.
I'm using the old cobalt branch with the version after ingress mode was
implement
as 1400+ bytes on the parisc stack, is a bit much. That said, I don't
see much possibility for shrinkage overall.
A) if we resort to having a struct new_cake_xstats[q->tin_cnt], we
still end up with a big stack on the diffserv8 case (that won't get
caught by a static checker)
B) I'm on record as
Yup, I wouldn't expect any difference at all in normal loads. Only when
you get some flows marked as unresponsive does the BLUE portion do anything.
- Jonathan Morton
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinf
This appears to panic (and has, very indirectly, caused my LEDE router
to wipe itself). Will take a closer look later.
Regards,
Ryan Mounce
On 6 December 2017 at 08:30, Dave Taht wrote:
> The attached patch attempts to deprioritize bulk ack flows in cake.
>
> Once we start accumulating enough a
This is all sorts of wrong.
First, setting the enum isn't sufficient to actually make the flow bulk.
You need to move it to the bulk queue-of-queues and update the stats
counters too. That's probably why it's crashing for Ryan.
Second, I fail to see why this is necessary or even desirable. If t
On Tue, Dec 5, 2017 at 10:08 PM, Jonathan Morton wrote:
> This is all sorts of wrong.
Going 1 out of 2 on untested patches for the day is not too horrible.
(sorry for crashing your router Ryan!!)
> First, setting the enum isn't sufficient to actually make the flow bulk.
> You need to move it to
12 matches
Mail list logo
