From: Eric Dumazet
Date: Thu, 23 Feb 2017 15:22:43 -0800
> From: Eric Dumazet
>
> The cited commit makes a great job of finding optimal shift/multiplier
> values assuming a 10 seconds wrap around, but forgot to change the
> overflow_period computation.
>
> It overflows in cyclecounter_cyc2ns()
On 24/02/2017 1:22 AM, Eric Dumazet wrote:
From: Eric Dumazet
The cited commit makes a great job of finding optimal shift/multiplier
values assuming a 10 seconds wrap around, but forgot to change the
overflow_period computation.
It overflows in cyclecounter_cyc2ns(), and the final result is
On Fri, Feb 24, 2017 at 6:21 PM, David Miller wrote:
> From: Eric Dumazet
> Date: Thu, 23 Feb 2017
> Tariq please review.
Dave,
Just to re-iterate what we wrote here couple of time, the IL WW is
Sun-Thu on GMT+2 hours and hence this patch was sent when the
developers/maintainer are into weeken
From: Eric Dumazet
Date: Thu, 23 Feb 2017 15:22:43 -0800
> From: Eric Dumazet
>
> The cited commit makes a great job of finding optimal shift/multiplier
> values assuming a 10 seconds wrap around, but forgot to change the
> overflow_period computation.
>
> It overflows in cyclecounter_cyc2ns()
From: Eric Dumazet
The cited commit makes a great job of finding optimal shift/multiplier
values assuming a 10 seconds wrap around, but forgot to change the
overflow_period computation.
It overflows in cyclecounter_cyc2ns(), and the final result is 804 ms,
which is silly.
Lets simply use 5 seco