On Tue, Dec 10, 2013 at 11:20:51AM +0100, Miroslav Lichvar wrote:
> What does the following line from your patch mean?
>
> tick_error -= tk->xtime_interval;
Ok, I think I understand how it should work. There are two loops, the
bigadjust one is correcting only for ntp tick length and the o
On Fri, Dec 06, 2013 at 05:43:45PM -0800, John Stultz wrote:
> Being that the bigadjust code, and specifically this lookahead bit, has
> always been the most opaque logic to me, I figured I'd spend some time
> looking at alternatives, and came up with one approach that tries to
> mimic your patch,
On 12/07/2013 09:56 AM, Richard Cochran wrote:
> On Fri, Dec 06, 2013 at 05:43:45PM -0800, John Stultz wrote:
>> Anyway, let me know what you think and I'll run some tests on it this
>> weekend.
>>
>> thanks
>> -john
>>
>>
>> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
>> ind
On Fri, Dec 06, 2013 at 05:43:45PM -0800, John Stultz wrote:
> Anyway, let me know what you think and I'll run some tests on it this
> weekend.
>
> thanks
> -john
>
>
> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> index 3abf534..bfb36fd 100644
> --- a/kernel/time/timekeep
On 12/06/2013 06:26 AM, Miroslav Lichvar wrote:
> This graph shows the value of tk->mult as it changes with clock
> updates:
> http://mlichvar.fedorapeople.org/tmp/tk_test1.png
>
> When the TSC frequency is set to 100 MHz, it becomes more pronounced:
> http://mlichvar.fedorapeople.org/tmp/tk_test2.
On Fri, Dec 06, 2013 at 10:09:03AM -0800, John Stultz wrote:
> On 12/06/2013 06:26 AM, Miroslav Lichvar wrote:
> > It seems to fix the problem with stability, that's good. But the
> > response seems to be very slow now. In the simulated test with 10Hz
> > clock update it takes about 1000 updates (1
On 12/06/2013 06:26 AM, Miroslav Lichvar wrote:
> On Mon, Dec 02, 2013 at 08:03:17PM -0800, John Stultz wrote:
>> On 12/02/2013 04:53 PM, John Stultz wrote:
>> Finally found a config to get it working (disabling kernel debugging
>> seems to work), and am currently trying to fixup the missing symbol
On Mon, Dec 02, 2013 at 08:03:17PM -0800, John Stultz wrote:
> On 12/02/2013 04:53 PM, John Stultz wrote:
> Finally found a config to get it working (disabling kernel debugging
> seems to work), and am currently trying to fixup the missing symbols
> (although I'm getting segfaults from various inli
On 12/02/2013 04:53 PM, John Stultz wrote:
> On 11/20/2013 10:39 AM, Miroslav Lichvar wrote:
>> On Mon, Nov 18, 2013 at 12:46:00PM -0800, John Stultz wrote:
In a simulation with 1GHz TSC clock and 10Hz clock update the maximum
error went down from 4.7 microseconds to 5.5 nanoseconds. With
On 11/20/2013 10:39 AM, Miroslav Lichvar wrote:
> On Mon, Nov 18, 2013 at 12:46:00PM -0800, John Stultz wrote:
>>> In a simulation with 1GHz TSC clock and 10Hz clock update the maximum
>>> error went down from 4.7 microseconds to 5.5 nanoseconds. With 1Hz
>>> update the maximum error went down from
On Tue, Nov 19, 2013 at 03:13:19PM +0100, Richard Cochran wrote:
>
> In this test, the update rate is once per second. When using longer
> intervals, the problem becomes worse.
Here is another pair of example runs on an idle system, this time with
a 32 second update interval.
* Periodic Case
On Mon, Nov 18, 2013 at 01:28:07PM -0800, John Stultz wrote:
> Also is this brokenness something that has been around for awhile for
> you or more recently cropped up? I'm wondering as nohz idle has been
> around for quite a few years and I've not seen too many complaints. So
> I'm wondering if I'
On Mon, Nov 18, 2013 at 12:46:00PM -0800, John Stultz wrote:
> Hmm. Reading this, but not having studied your patch in depth, is
> interesting. It originally was that we only applied any NTP adjustment
> to future changes. Also, since at that time the tick length was only
> changed on the second ov
On Mon, Nov 18, 2013 at 01:28:07PM -0800, John Stultz wrote:
> Also, just for clarity's sake, when you're seeing things "broken",
> curious how/what you are measuring?
Here is the background for this issue. The linuxptp stack has a
program called phc2sys whose purpose is to synchronize the Linux
On 11/15/2013 11:03 PM, Richard Cochran wrote:
> On Thu, Nov 14, 2013 at 03:50:40PM +0100, Miroslav Lichvar wrote:
>
>> include/linux/timekeeper_internal.h | 4 +
>> kernel/time/timekeeping.c | 209
>> +---
>> 2 files changed, 31 insertions(+), 182 dele
On 11/14/2013 06:50 AM, Miroslav Lichvar wrote:
> Since commit 5eb6d205 the system clock is kept separately from NTP time
> and it is synchronized by adjusting its multiplier in a feedback loop.
> This works well when the updates are done regularly. With nohz and idle
> system, however, the loop be
On Thu, Nov 14, 2013 at 03:50:40PM +0100, Miroslav Lichvar wrote:
> include/linux/timekeeper_internal.h | 4 +
> kernel/time/timekeeping.c | 209
> +---
> 2 files changed, 31 insertions(+), 182 deletions(-)
This looks like an impressive simplification
On 11/14/2013 09:50 AM, Miroslav Lichvar wrote:
Since commit 5eb6d205 the system clock is kept separately from NTP time
and it is synchronized by adjusting its multiplier in a feedback loop.
This works well when the updates are done regularly. With nohz and idle
system, however, the loop becomes
18 matches
Mail list logo
