Johannes Berg writes:
> On Fri, 2019-02-22 at 14:40 +0100, Toke Høiland-Jørgensen wrote:
>>
>> And send it directly to stable, or does it need to go through you?
>
> I added a Cc: stable tag. So all you really need to do is wait for the
> emails telling you it failed to apply, and handle
On Fri, 2019-02-22 at 14:40 +0100, Toke Høiland-Jørgensen wrote:
>
> And send it directly to stable, or does it need to go through you?
I added a Cc: stable tag. So all you really need to do is wait for the
emails telling you it failed to apply, and handle accordingly :)
johannes
Johannes Berg writes:
> On Fri, 2019-02-22 at 14:06 +0100, Toke Høiland-Jørgensen wrote:
>> Johannes Berg writes:
>>
>> > Toke Høiland-Jørgensen wrote:
>> >
>> > > When we did the original tests for the optimal value of sk_pacing_shift,
>> > > we
>> > > came up with 6 ms of buffering as the
On Fri, 2019-02-22 at 14:06 +0100, Toke Høiland-Jørgensen wrote:
> Johannes Berg writes:
>
> > Toke Høiland-Jørgensen wrote:
> >
> > > When we did the original tests for the optimal value of sk_pacing_shift,
> > > we
> > > came up with 6 ms of buffering as the default. Sadly, 6 is not a power
Johannes Berg writes:
> Toke Høiland-Jørgensen wrote:
>
>> When we did the original tests for the optimal value of sk_pacing_shift, we
>> came up with 6 ms of buffering as the default. Sadly, 6 is not a power of
>> two, so when picking the shift value I erred on the size of less buffering
>> and
When we did the original tests for the optimal value of sk_pacing_shift, we
came up with 6 ms of buffering as the default. Sadly, 6 is not a power of
two, so when picking the shift value I erred on the size of less buffering
and picked 4 ms instead of 8. This was probably wrong; those 2 ms of
