It sounds like COBALT should be a bit smoother in terms of recovery/switch
time from one state to another - if this is the case, I would say that it
is a nice improvement - FQ_CODEL is smooth/fast in it's transition (at
least in my observations on a ping test while running multiple streams to
the b
> On 20 May, 2016, at 19:43, Jonathan Morton wrote:
>
>> On 20 May, 2016, at 19:37, Luis E. Garcia wrote:
>>
>> I think this would be a great idea to implement and test.
>> Can COBALT's behavior be easily implemented to test it using the OpenWRT or
>> LEVE ?
>
> I assume you mean LEDE.
>
>
> On 20 May, 2016, at 19:03, David Lang wrote:
>
> On Fri, 20 May 2016, Jonathan Morton wrote:
>
If the relative load from the flow decreases, BLUE’s action will begin to
leave the subqueue empty when serviced, causing BLUE’s drop probability to
fall off gradually, potentially
> On 20 May, 2016, at 19:05, David Lang wrote:
>
> don't know, I was thinking more the dslreports speedtest site and that sort
> of thing.
I imagine both dslreports and netalyzr would find this metric interesting, if
they don’t have it already. They’re both in a position to examine packet
t
That sounds nice.
I have a few spare x86 mini routers that would be useful as test beds.
* Yeah, I meant LEDE - I'm still adjusting to the new vocabulary.
Luis
On Fri, May 20, 2016 at 10:43 AM, Jonathan Morton
wrote:
>
> > On 20 May, 2016, at 19:37, Luis E. Garcia wrote:
> >
> > I think this
> On 20 May, 2016, at 19:37, Luis E. Garcia wrote:
>
> I think this would be a great idea to implement and test.
> Can COBALT's behavior be easily implemented to test it using the OpenWRT or
> LEVE ?
I assume you mean LEDE.
Yes, the BLUE algorithm is very simple (and is already in Linux, if y
Jonathan,
I think this would be a great idea to implement and test.
Can COBALT's behavior be easily implemented to test it using the OpenWRT or
LEVE ?
Regards,
Luis
On Fri, May 20, 2016 at 8:36 AM, Jonathan Morton
wrote:
> >> If the relative load from the flow decreases, BLUE’s action will begi
On Fri, 20 May 2016, Jonathan Morton wrote:
On 20 May, 2016, at 17:04, David Lang wrote:
Is it possible to get speed testing software to detect that it's receiving
fragments and warn about that?
Do iperf3’s maintainers accept patches?
don't know, I was thinking more the dslreports speedte
On Fri, 20 May 2016, Jonathan Morton wrote:
If the relative load from the flow decreases, BLUE’s action will begin to
leave the subqueue empty when serviced, causing BLUE’s drop probability to
fall off gradually, potentially until it reaches zero. At this point the
subqueue is naturally reset
> On 20 May, 2016, at 17:04, David Lang wrote:
>
> Is it possible to get speed testing software to detect that it's receiving
> fragments and warn about that?
Do iperf3’s maintainers accept patches?
- Jonathan Morton
___
Cake mailing list
Cake@lis
>> If the relative load from the flow decreases, BLUE’s action will begin to
>> leave the subqueue empty when serviced, causing BLUE’s drop probability to
>> fall off gradually, potentially until it reaches zero. At this point the
>> subqueue is naturally reset and will react normally to subseq
> On 20 May, 2016, at 16:41, David Lang wrote:
>
> On Fri, 20 May 2016, Jonathan Morton wrote:
>
>> Normal traffic does not include large numbers of fragmented packets (I would
>> expect a mere handful from certain one-shot request-response protocols which
>> can produce large responses), so
On Fri, 20 May 2016, moeller0 wrote:
On May 20, 2016, at 15:41 , David Lang wrote:
On Fri, 20 May 2016, Jonathan Morton wrote:
Normal traffic does not include large numbers of fragmented packets (I would
expect a mere handful from certain one-shot request-response protocols which
can produ
> On May 20, 2016, at 15:41 , David Lang wrote:
>
> On Fri, 20 May 2016, Jonathan Morton wrote:
>
>> Normal traffic does not include large numbers of fragmented packets (I would
>> expect a mere handful from certain one-shot request-response protocols which
>> can produce large responses), so
On Fri, 20 May 2016, Jonathan Morton wrote:
Normal traffic does not include large numbers of fragmented packets (I would
expect a mere handful from certain one-shot request-response protocols which
can produce large responses), so it is better to shunt them to a single queue
per host-pair.
I
Hi Jonathan,
> On May 20, 2016, at 14:18 , Jonathan Morton wrote:
>
>>> One of the major reasons why Codel fails on UDP floods is that its drop
>>> schedule is time-based. This is the correct behaviour for TCP flows, which
>>> respond adequately to one congestion signal per RTT, regardless of
>> One of the major reasons why Codel fails on UDP floods is that its drop
>> schedule is time-based. This is the correct behaviour for TCP flows, which
>> respond adequately to one congestion signal per RTT, regardless of the
>> packet rate. However, it means it is easily overwhelmed by high-
Hi Jonathan,
interesting ideas.
> On May 20, 2016, at 12:04 , Jonathan Morton wrote:
>
> With the recent debate over handling unresponsive flows in fq_codel, I had a
> brainwave involving constructing a hybrid AQM which preserves Codel’s
> excellent properties on responsive flows, while also
With the recent debate over handling unresponsive flows in fq_codel, I had a
brainwave involving constructing a hybrid AQM which preserves Codel’s excellent
properties on responsive flows, while also reacting appropriately when faced
with a UDP flood. The key difficulty was deciding when to swi
19 matches
Mail list logo
