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
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 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, but
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
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
>>
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
> ---
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/timekeeping.c
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
index
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:
>
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
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
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
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 inline
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 symbols
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 (100
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.png
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.
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
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 480
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 1Hz
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 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
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'm
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
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
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
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
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
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
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 deletions(-)
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
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
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 unstable at a certain update interval.
The loop
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 unstable at a certain update interval.
The loop
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
38 matches
Mail list logo
