On Thu, Sep 20, 2018 at 11:19 AM Sebastian Moeller wrote:
>
> Hi Dave,
>
> please excuse my apparent impatience, all I wanted to convey is that only
> after proper testing should we roll-out the new burst configuration mode to
> all users ;) . One thing we should have by then is a decent idea
Hi Dave,
please excuse my apparent impatience, all I wanted to convey is that only after
proper testing should we roll-out the new burst configuration mode to all users
;) . One thing we should have by then is a decent idea of what to select as
default burst duration. But since this is not
On Thu, Sep 20, 2018 at 3:34 AM Sebastian Moeller wrote:
>
> Hi Dave,
>
>
>
> > On Sep 19, 2018, at 19:02, Dave Taht wrote:
> >
> > thx!
>
> You are welcome, but does this actually work for you? I want to clean
> up things by removing the old burst scaling mode, but want/need
Hi Dave,
> On Sep 19, 2018, at 19:02, Dave Taht wrote:
>
> thx!
You are welcome, but does this actually work for you? I want to clean
up things by removing the old burst scaling mode, but want/need confirmation
that the new duration based method actually works as intended. (My next
thx!
On Wed, Sep 19, 2018 at 6:28 AM Sebastian Moeller wrote:
>
> Hi Dave, hi All,
>
> so I tried to run with this idea and prototyped something into the
> burst_by_duration branch at the sqm repository. Would be interested to hear
> whether that does "the right thing" with your APU or on
Hi Dave, hi All,
so I tried to run with this idea and prototyped something into the
burst_by_duration branch at the sqm repository. Would be interested to hear
whether that does "the right thing" with your APU or on other's devices? The
key variable is TARGET_BURST_DUR_MS in defaults.sh. Let
On Tue, Sep 11, 2018 at 11:45 AM Pete Heist wrote:
>
>
> On Sep 11, 2018, at 8:28 PM, Sebastian Moeller wrote:
>
>
> Yeah, good point, I left nat there because I had one port configured for
> routing and the other for the bridge and was sometimes swapping between the
> two. I realize now I
> On Sep 11, 2018, at 8:28 PM, Sebastian Moeller wrote:
>>
>> Yeah, good point, I left nat there because I had one port configured for
>> routing and the other for the bridge and was sometimes swapping between the
>> two. I realize now I actually sent the numbers for routing, not bridging.
Next time I have sufficient spare brain cells I would like to try
shaping across cores. I don't know how to
share a bit of data between qdiscs as yet, so my plan to prove it out,
is to use a static variable for time_next_packet (has to be 32 bits
also), and atomically update it between the
that was me shaping at 900.
On Tue, Sep 11, 2018 at 11:27 AM Pete Heist wrote:
>
>
> > On Sep 11, 2018, at 10:20 AM, Dave Taht wrote:
> >
> > What I "fixed" was on the apu2 with the burst/cburst change, I went
> > from completely bottlenecked on one softirq to having 3 eat cpu, and
> > from
Hi Pete,
> On Sep 11, 2018, at 20:09, Pete Heist wrote:
>
>
>> On Sep 11, 2018, at 9:54 AM, Sebastian Moeller wrote:
>>>
>>> So this has turned info an interesting exercise that produced a result
>>> counter to what the common wisdom has been (that fq_codel is “faster” than
>>> cake
>>
> On Sep 11, 2018, at 10:20 AM, Dave Taht wrote:
>
> What I "fixed" was on the apu2 with the burst/cburst change, I went
> from completely bottlenecked on one softirq to having 3 eat cpu, and
> from 400mbps to 900mbps. Now, that's a quad core and the e1000 (?)
> driver. The edgerouter X is a
Hi Dave,
> On Sep 11, 2018, at 10:30, Dave Taht wrote:
>
> On Tue, Sep 11, 2018 at 1:20 AM Sebastian Moeller wrote:
>>
>> Hi Dave,
>>
>>> On Sep 11, 2018, at 10:20, Dave Taht wrote:
>>>
>>> What I "fixed" was on the apu2 with the burst/cburst change, I went
>>> from completely
On Tue, Sep 11, 2018 at 1:20 AM Sebastian Moeller wrote:
>
> Hi Dave,
>
> > On Sep 11, 2018, at 10:20, Dave Taht wrote:
> >
> > What I "fixed" was on the apu2 with the burst/cburst change, I went
> > from completely bottlenecked on one softirq to having 3 eat cpu, and
> > from 400mbps to
Hi Dave,
> On Sep 11, 2018, at 10:20, Dave Taht wrote:
>
> What I "fixed" was on the apu2 with the burst/cburst change, I went
> from completely bottlenecked on one softirq to having 3 eat cpu, and
> from 400mbps to 900mbps. Now, that's a quad core and the e1000 (?)
> driver. The edgerouter X
What I "fixed" was on the apu2 with the burst/cburst change, I went
from completely bottlenecked on one softirq to having 3 eat cpu, and
from 400mbps to 900mbps. Now, that's a quad core and the e1000 (?)
driver. The edgerouter X is a dual core, and you did see a small
improvement in throughput,
Hi Pete,
> On Sep 11, 2018, at 00:40, Pete Heist wrote:
>
> Subject changed from “Cake on elements of a bridge”...
>
> On Sep 10, 2018, at 9:55 PM, Dave Taht wrote:
>>
>> On Mon, Sep 10, 2018 at 12:29 PM Pete Heist wrote:
>>>
>>> For anyone who followed this, yes, the regular soft bridge
Subject changed from “Cake on elements of a bridge”...
On Sep 10, 2018, at 9:55 PM, Dave Taht wrote:
>
> On Mon, Sep 10, 2018 at 12:29 PM Pete Heist wrote:
>>
>> For anyone who followed this, yes, the regular soft bridge (i.e. set
>> interfaces bridge br0) works fine on the ER-X, as I
18 matches
Mail list logo
