>> 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
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
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
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
> 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
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
> 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
"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 need
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 need to do is try to enqueue another one at this
> point.