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 excitement you know :)
__
> 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…
- Jonathan Morton
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.
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 6 Oct, 2016, at 07:19, Dave Taht wrote:
>
> master
Right - that’s stable code. I’m doing experimental stuff in the cobalt branch.
- Jonathan Morton
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
master
On Wed, Oct 5, 2016 at 8:59 PM, Kevin Darbyshire-Bryant
wrote:
>
>
> 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'?
--
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
>> 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 ever since. Another
> machine is
I cannot repeat that result this morning, with either replace or
change. I *was* running far more extensive tests between changing
things that way than I just did, but a string of quick tests, changing
the bandwidth, changing it to unlimited, etc got the correct behaviors
throughout for both replac
> On 5 Oct, 2016, at 18:55, Kevin Darbyshire-Bryant
> wrote:
>
> I don't trust tc replace and I'm pretty sure we've been here before.
Does tc change (with the same arguments otherwise) behave any differently?
- Jonathan Morton
___
Cake mailing lis
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
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 qdisc replace dev eth0 root cake bandwi
> On 5 Oct, 2016, at 18:45, Kevin Darbyshire-Bryant
> 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, bu
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 helpful to
> 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 helpful to a remote accessed, no serial in
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
15 matches
Mail list logo
