Copy the modified timex data back to the user also with positive return
values. This fixes reading of the CLOCK_REALTIME timex data when the
clock is in a non-zero state.
Signed-off-by: Miroslav Lichvar mlich...@redhat.com
---
kernel/posix-timers.c | 2 +-
1 file changed, 1 insertion(+), 1
The clock_adj call returns the clock state on success, which may be a
non-zero value (e.g. TIME_INS), but the modified timex data is copied
back to the user only when zero value (TIME_OK) was returned. Fix the
condition to copy the data also with positive return values.
Signed-off-by: Miroslav
to 10 ticks. As a typical RTC drifts in the 11-minute
update interval by several milliseconds, this shouldn't affect the
overall accuracy of the RTC much.
Signed-off-by: Miroslav Lichvar mlich...@redhat.com
---
kernel/time/ntp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
it after adjtimex() to improve
accuracy of phase adjustments done by quickly changing NTP frequency
- check if there are any issues with suspend
Signed-off-by: Miroslav Lichvar mlich...@redhat.com
---
include/linux/timekeeper_internal.h | 4 +
kernel/time/timekeeping.c | 209
be an acceptable replacement.
A different approach to fix this problem would be controlling the
maximum idle interval from the tick adjusting code so that the NTP
error corrections can be accurate. That would further increase the
complexity of the code and increase the interrupt rate.
--
Miroslav
in the kernel
timekeeping.
--
Miroslav Lichvar
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
.
I've noticed there is a division in logarithmic_accumulation(), which
is used as a workaround for an older compiler bug. Perhaps it could be
removed now, so there is more space for this one?
Please reconsider.
Thanks,
--
Miroslav Lichvar
From 150e7c8ed96d078d025f154c219c0a4367a401fc Mon Sep 17 00
On Mon, May 19, 2014 at 10:57:29AM -0700, John Stultz wrote:
On Mon, May 19, 2014 at 3:14 AM, Miroslav Lichvar mlich...@redhat.com wrote:
Ok, so it seems to be almost identical to my patch now. The only two
differences seem to be the removal of the ntp_error correction to
change
74.1279.9
nohz off 0.06275 0.06440 0.4 1.4
--
Miroslav Lichvar
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
; look_ahead++)
error2 = 2;
--
Miroslav Lichvar
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 every update. The bigadjust correction seems too weak to
bring the error down to activate the normal +1/-1 adjustment, the
error keeps increasing and the frequency is slighly off.
What does the following line from your patch mean?
tick_error -= tk-xtime_interval;
--
Miroslav Lichvar
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
On Fri, Apr 25, 2014 at 02:05:49PM -0700, John Stultz wrote:
On 04/25/2014 07:04 AM, Miroslav Lichvar wrote:
It seems it still doesn't always switch mult only between the two
closest values, which explains the slightly worse dev and max values.
Huh. I don't think I saw that in my testing
On Wed, Apr 23, 2014 at 09:22:45PM -0700, John Stultz wrote:
On 02/12/2014 07:42 AM, Miroslav Lichvar wrote:
You can see in this test it takes about 2500 updates to correct the
initial ntp error and settle down. That's with 1GHz clocksource. In
some tests I did with smaller clock
it still doesn't always switch mult only between the two
closest values, which explains the slightly worse dev and max values.
Thanks,
--
Miroslav Lichvar
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo
complicate the mult
adjustment logic and bring back the problems which the direct division
approach is supposed to solve.
It seems it may be a while before the old vsyscalls are fixed. How
about including only the first two patches from this set for now?
Thanks,
--
Miroslav Lichvar
--
To unsubscribe
() fixes that.
I've some comments on the performance of the proposed code, I'll send
them in a separate mail later.
Thanks,
--
Miroslav Lichvar
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
On Tue, Jul 15, 2014 at 09:02:38PM -0700, John Stultz wrote:
On 07/08/2014 04:08 AM, Miroslav Lichvar wrote:
It seems it may be a while before the old vsyscalls are fixed. How
about including only the first two patches from this set for now?
Hey! Sorry for the slow response here, I
-status STA_PLL)
+ (time_state != TIME_OOP)) {
time_state = TIME_OK;
time_status = STA_UNSYNC;
/* restart PPS frequency calibration */
Shouldn't be time_status reset and the PPS calibration restarted even
when state is TIME_OOP?
--
Miroslav
On Thu, Feb 05, 2015 at 08:20:08AM -0500, Prarit Bhargava wrote:
On 02/04/2015 11:30 AM, Miroslav Lichvar wrote:
If after that, adjtimex() will return with TIME_ERROR as expected, or
not?
It is possible that an adjtimex() will set the time_state here back to TIME_OK
and return TIME_OK
before ktime_t overflow. The default value is 1 with
32-bit time_t and 2 with 64-bit time_t. This can be changed later to be
always 2 when 64-bit versions of system calls using 32-bit time_t are
available.
Signed-off-by: Miroslav Lichvar mlich...@redhat.com
---
Documentation/sysctl/kernel.txt | 19
On Wed, Apr 15, 2015 at 10:31:54PM +0100, One Thousand Gnomes wrote:
On Wed, 15 Apr 2015 17:41:28 +0200
Miroslav Lichvar mlich...@redhat.com wrote:
larger value. When the maximum is reached in normal time accumulation,
the clock will be stepped back by one week.
Which itself is open
reached, stepping
back\n);
+ }
+
+ if (unlikely(step)) {
struct timespec64 ts;
- tk-xtime_sec += leap;
+ tk-xtime_sec += step;
--
Miroslav Lichvar
--
To unsubscribe from this list: send
think?
--
Miroslav Lichvar
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Wed, Oct 07, 2015 at 05:10:34PM +0200, Arnd Bergmann wrote:
> On Wednesday 07 October 2015 16:23:44 Miroslav Lichvar wrote:
> > Without the limit added by this patch make will go nuts just one week
> > later when the 32-bit time_t overflows to Dec 13 1901 and the files
> &g
On Thu, Oct 08, 2015 at 10:52:05AM +0200, Arnd Bergmann wrote:
> On Thursday 08 October 2015 08:23:44 Miroslav Lichvar wrote:
> > The difference is that with the one-week step the kernel and userspace
> > still agree on the current time and it is always valid from the kernel
&g
ack one week sooner to prevent
also time_t overflowing in majority of the user-space code, it could
be moved closer to the actual overflow. I don't see the benefit
though.
Similar applies to KTIME_MAX and the kernel code.
--
Miroslav Lichvar
--
To unsubscribe from this list: send the
hargava <pra...@redhat.com>
Cc: Richard Cochran <richardcoch...@gmail.com>
Cc: Arnd Bergmann <a...@arndb.de>
Signed-off-by: Miroslav Lichvar <mlich...@redhat.com>
---
v2: - optimized code in accumulate_nsecs_to_secs() a bit
- improved log message and increased its level to warni
On Wed, Oct 07, 2015 at 03:47:19PM +0200, Arnd Bergmann wrote:
> On Wednesday 07 October 2015 15:22:17 Miroslav Lichvar wrote:
> > This patch sets a maximum value of the system time to prevent the system
> > time from getting too close to the overflow. The time can't be set to a
&
On Fri, Oct 09, 2015 at 12:38:32PM +0200, Thomas Gleixner wrote:
> On Fri, 9 Oct 2015, Miroslav Lichvar wrote:
> > Do you feel the same about preventing the time from reaching
> > KTIME_MAX?
>
> That's going to happen in ~500 years from now.
At any time if you include
On Fri, Oct 09, 2015 at 10:46:16AM +0100, Thomas Gleixner wrote:
> On Thu, 8 Oct 2015, Miroslav Lichvar wrote:
> > Applications are not allowed to rely on system time being sane?
> > To me the current behavior looks like the kernel is throwing the
> > applications off a cliff
h
nohz=off, so I thought it was something else. Now that it seems it
indeed is related to nohz, I guess it's not a problem with the clock
update interval being too long (which the referenced commit
addressed).
Anyone knows what values (mask, mult, shift, maxadj) has the
clocksource in this case? I'd l
C_RAW clocks when the
adjtimex tick is set to 9000. It should show values close to -10
ppm and I suspect on the BBB it will be much smaller.
--
Miroslav Lichvar
#include
#include
#include
#include
#define DIFFTS(a, b) ((a.tv_sec - b.tv_sec) + 1e-9 * (a.tv_nsec - b.tv_nsec))
int main() {
is not 100 on all archs.
> + for (tick = 9000; tick < 11000; tick += 250)
> + if (check_tick_adj(tick)) {
This too.
> + tx1.tick = 1;
> + adjtimex();
And this too.
--
Miroslav Lichvar
--
To unsubscribe from this list: send the line "unsubscribe linu
usec, 74990 ppm [OK]
The precision of the clock is better than microsecond, so that
wouldn't explain a 12 ppm error over the 15 second interval. I guess
it's due to a larger xtime_remainder, which basically is a hidden
frequency offset added (and not multiplied) to the NTP frequency
offset. Would
On Thu, Sep 10, 2015 at 11:14:25AM -0700, John Stultz wrote:
> On Thu, Sep 10, 2015 at 10:42 AM, John Stultz <john.stu...@linaro.org> wrote:
> > On Thu, Sep 10, 2015 at 5:02 AM, Miroslav Lichvar <mlich...@redhat.com>
> > wrote:
> >> The precision of the
/* scale the corrections */
> - timekeeping_apply_adjustment(tk, offset, negative, adj);
> + timekeeping_apply_adjustment(tk, offset, negative, adj_scale);
--
Miroslav Lichvar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ld be moved to
timekeeping_apply_adjustment()? It would try decreasing adj_scale
until the check passes. When it reached -1, the function would return
immediately with no adjustment of the multiplier.
--
Miroslav Lichvar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel
ly to push us past the limit, as pointed
> out by Miroslav.
> v3: Fix off-by-one case that could result in warning
> still triggering, pointed out by Miroslav.
Looks good to me. There are no warnings in the simulator and chronyd
still seems to be working as expected.
Tested-by: Miroslav L
option to not use the PRECISE ioctl even if it's supported.
--
Miroslav Lichvar
st one read is enough, this hack could be even better.
>
> I'd be afraid of messing up chrony's stats...
This should be ok. For the application it just looks as if the CPU and
everything else in the path of the measurements was infinitely fast. :)
--
Miroslav Lichvar
is accurate and not include any delay/dispersion in an
estimate of the maximum error, which is needed in NTP for instance.
If we know the host timestamp ts[1] is not in the middle between the
guests timestamps ts[0] and ts[2], but rather closer to ts[2], why not
simply shift ts[1] by (ts[2]-ts[0])/2 ?
--
Miroslav Lichvar
+-+
| |
| |
Guest time +-+-+..
ts[0]ts[2] ts[4]
--
Miroslav Lichvar
two
NICs with HW timestamping.
--
Miroslav Lichvar
gc, char **argv)
> ksft_exit_fail();
>
> ksft_exit_pass();
> +
> + return 0;
> }
It seems most tests use "return ksft_exit_pass();". Would that be
preferred over separate return? I don't have a preference.
Both patches in this set look good to me.
Thanks,
--
Miroslav Lichvar
d init_test(void)
>
> if (precision > MAX_PRECISION) {
> printf("[SKIP]\n");
> - ksft_exit_skip();
> + ksft_exit_skip("[SKIP]\n");
To avoid printing "skip" multiple times, I'd suggest to change the
argument of ksft_exit_skip to NULL.
Thanks,
--
Miroslav Lichvar
On Fri, May 12, 2017 at 10:26:12AM -0700, John Stultz wrote:
> On Fri, May 12, 2017 at 8:14 AM, Miroslav Lichvar <mlich...@redhat.com> wrote:
> > I see this with real PHCs and PTP/NTP synchronization too. It's very
> > confusing when the timekeeping changes so much f
As the last users of CONFIG_GENERIC_TIME_VSYSCALL_OLD have been updated,
the support can be removed from the timekeeping code.
Cc: John Stultz <john.stu...@linaro.org>
Cc: Prarit Bhargava <pra...@redhat.com>
Cc: Richard Cochran <richardcoch...@gmail.com>
Signed-off-by: Miros
that breaks frequently as the timekeeping and
other kernel code changes. Are you sure you want that in the kernel
tree? :)
--
Miroslav Lichvar
<john.stu...@linaro.org>
Cc: Prarit Bhargava <pra...@redhat.com>
Cc: Richard Cochran <richardcoch...@gmail.com>
Signed-off-by: Miroslav Lichvar <mlich...@redhat.com>
---
include/linux/timekeeper_internal.h | 2 +
kernel/time/timekeeping.c | 137 -
0.0 0.2 0.6
30.0 0.3 0.6 0.0 0.2 0.6
10 0.0 0.3 0.6 0.0 0.2 0.6
Miroslav Lichvar (3):
timekeeping: Remove support for old vsyscalls
timekeeping: Don't align frequency adjustments to ticks
to keep the point where the frequency is
effectively changed at the time of the update. This removes a major
source of the NTP error.
Cc: John Stultz <john.stu...@linaro.org>
Cc: Prarit Bhargava <pra...@redhat.com>
Cc: Richard Cochran <richardcoch...@gmail.com>
Signed-off-by: Miros
On Wed, May 17, 2017 at 10:02:00AM -0700, John Stultz wrote:
> On Wed, May 17, 2017 at 9:57 AM, Miroslav Lichvar <mlich...@redhat.com> wrote:
> > On Wed, May 17, 2017 at 09:30:31AM -0700, John Stultz wrote:
> >> Could you submit your linux-tktest infrastructure to the kself
On Tue, Jul 15, 2014 at 09:02:38PM -0700, John Stultz wrote:
> On 07/08/2014 04:08 AM, Miroslav Lichvar wrote:
> > I spent some time trying to figure out a workaround for the nanosecond
> > rounding, but I didn't find anything that wouldn't complicate the mult
> > adjustment
On Fri, May 19, 2017 at 05:35:38PM -0700, John Stultz wrote:
> >> On Wed, May 17, 2017 at 10:22 AM, Miroslav Lichvar <mlich...@redhat.com>
> >> wrote:
> >> > Is there a better way to run the timekeeping code in an userspace
> >> > application?
or in-kernel users.
The patch looks good to me and in testing on x86_64 I didn't see any
issues with the CLOCK_MONOTONIC_RAW clock.
Thanks,
--
Miroslav Lichvar
Prarit Bhargava <pra...@redhat.com>
Cc: Richard Cochran <richardcoch...@gmail.com>
Signed-off-by: Miroslav Lichvar <mlich...@redhat.com>
---
tools/testing/selftests/timers/inconsistency-check.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/
exceed specified limits.
Cc: John Stultz <john.stu...@linaro.org>
Cc: Richard Cochran <richardcoch...@gmail.com>
Cc: Prarit Bhargava <pra...@redhat.com>
Signed-off-by: Miroslav Lichvar <mlich...@redhat.com>
---
tools/testing/selftests/timers/Makefile| 5 +-
tools/testi
240 |
>
> Using so_txtime, the peak to peak jitter is about 100 nanoseconds,
Nice!
--
Miroslav Lichvar
all, and not at all seems slightly better in my mind.
Yeah, controlling the clock in such conditions will be difficult. The
kernel/ntp PLL requires periodic updates. There is some code in
ntp_update_offset() that reduces the frequency adjustment when PLL
updates are missing, but I'm not actually sure if it works correctly
with suspend.
--
Miroslav Lichvar
may fail.
Maybe this test and other tests that measure the frequency of the
system clock should be modified to SKIP when adjtimex() returns a
non-zero offset (or the frequency changes during the test)?
--
Miroslav Lichvar
control of the system clock
with update rates close to or even exceeding the kernel HZ.
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: John Stultz <john.stu...@linaro.org>
Cc: Richard Cochran <richardcoch...@gmail.com>
Cc: Prarit Bhargava <pra...@redhat.com>
Signed-off-by:
On Wed, May 23, 2018 at 11:05:34AM -0700, John Stultz wrote:
> On Wed, May 23, 2018 at 4:33 AM, Miroslav Lichvar <mlich...@redhat.com> wrote:
> > This removes a hidden non-deterministic delay in setting of the
> > frequency and allows an extremely tight control of the system
control of the system clock
with update rates close to or even exceeding the kernel HZ.
Cc: Thomas Gleixner
Cc: John Stultz
Cc: Richard Cochran
Cc: Prarit Bhargava
Signed-off-by: Miroslav Lichvar
---
Notes:
RFC->v1:
- added a new parameter to force the update of the timekee
control of the system clock
with update rates close to or even exceeding the kernel HZ.
The update is limited to archs using modern timekeeping
(!ARCH_USES_GETTIMEOFFSET).
Cc: Thomas Gleixner
Cc: John Stultz
Cc: Richard Cochran
Cc: Prarit Bhargava
Signed-off-by: Miroslav Lichvar
---
Notes:
RFC
On Tue, May 29, 2018 at 10:42:05AM -0700, John Stultz wrote:
> On Tue, May 29, 2018 at 3:53 AM, Miroslav Lichvar wrote:
> > -void update_wall_time(void)
> > +static void timekeeping_advance(bool force_update)
>
> This is kind of a nit, but mind switching out bool for an enu
000 3 12 +0.000 4 11 [OK]
Miroslav Lichvar (2):
timekeeping: Don't align frequency adjustments to ticks
timekeeping: Determine multiplier directly from NTP tick length
include/linux/timekeeper_internal.h | 2 +
kernel/time/timekeeping.c |
the point where the frequency is
effectively changed at the time of the update. This removes a major
source of the NTP error.
Cc: John Stultz <john.stu...@linaro.org>
Cc: Prarit Bhargava <pra...@redhat.com>
Cc: Richard Cochran <richardcoch...@gmail.com>
Signed-off-by: Miros
<john.stu...@linaro.org>
Cc: Prarit Bhargava <pra...@redhat.com>
Cc: Richard Cochran <richardcoch...@gmail.com>
Signed-off-by: Miroslav Lichvar <mlich...@redhat.com>
---
include/linux/timekeeper_internal.h | 2 +
kernel/time/timekeeping.c | 138 -
5 [OK]
10 +0.000 3 12 +0.000 4 11 [OK]
Miroslav Lichvar (2):
timekeeping: Don't align frequency adjustments to ticks
timekeeping: Determine multiplier directly from NTP tick length
include/linux/timekeeper_internal.h | 2 +
kernel/time/timekeepin
T in progress. Shutdown
NTPd or other time steering daemons\n");
+ return ksft_exit_skip("The clock was adjusted. Shutdown
ntpd or other time steering daemons\n");
}
printf(" [FAILED]\n");
return ksft_exit_fail();
--
Miroslav Lichvar
}
> printf("[FAILED]\n");
> return ksft_exit_fail();
> }
> --
> 2.7.4
>
--
Miroslav Lichvar
: Prarit Bhargava <pra...@redhat.com>
Cc: Richard Cochran <richardcoch...@gmail.com>
Cc: Stephen Boyd <stephen.b...@linaro.org>
Signed-off-by: Miroslav Lichvar <mlich...@redhat.com>
---
tools/testing/selftests/timers/freq-step.c | 6 +++---
1 file changed, 3 insertions(
onized CPUs)?
If the frequency error was exported, it could be compensated where
necessary. Maybe that would work for the original poster?
A better fix might be to modify the calculation of time to use a
second multiplier, effectively increasing its resolution. However,
that would slow down all users of the clock.
--
Miroslav Lichvar
On Wed, Oct 24, 2018 at 01:32:48PM -0400, Christopher Hall wrote:
> On Wed, Oct 24, 2018 at 04:51:13PM +0200, Miroslav Lichvar wrote:
> > The error is too large to be corrected by stepping on clock updates.
> > For a typical TSC frequency we have multiplier in the range of few
&
k which is
separate from the mono/real clock, and add an offset to the NTP
frequency to match the frequencies of the two clocks when not
synchronized by NTP/PTP. The latter would provide a more stable
mono/real clock.
clocksource -> MONOTONIC_RAW -> MONOTONIC/REALTIME
or
clocksource -> ? -> MONOTONIC_RAW
-> MONOTONIC/REALTIME
--
Miroslav Lichvar
On Thu, Nov 01, 2018 at 06:41:00PM +0100, Thomas Gleixner wrote:
> On Wed, 24 Oct 2018, Miroslav Lichvar wrote:
> > The error is too large to be corrected by stepping on clock updates.
> > For a typical TSC frequency we have multiplier in the range of few
> > millions, so tha
On Fri, Nov 02, 2018 at 12:25:56PM +0100, Thomas Gleixner wrote:
> On Fri, 2 Nov 2018, Miroslav Lichvar wrote:
> > clocksource -> MONOTONIC_RAW -> MONOTONIC/REALTIME
> >
> > or
> >
> > clocksource -> ? -> MONOTONIC_RAW
> >
to 10 ticks. As a typical RTC drifts in the 11-minute
update interval by several milliseconds, this shouldn't affect the
overall accuracy of the RTC much.
Signed-off-by: Miroslav Lichvar
---
kernel/time/ntp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/time/ntp.c b
it after adjtimex() to improve
accuracy of phase adjustments done by quickly changing NTP frequency
- check if there are any issues with suspend
Signed-off-by: Miroslav Lichvar
---
include/linux/timekeeper_internal.h | 4 +
kernel/time/timekeeping.c | 209
fundamental problems in the design and
whether it would be an acceptable replacement.
A different approach to fix this problem would be controlling the
maximum idle interval from the tick adjusting code so that the NTP
error corrections can be accurate. That would further increase the
complexity of
dea there could be a problem in the kernel
timekeeping.
--
Miroslav Lichvar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
the code.
I've noticed there is a division in logarithmic_accumulation(), which
is used as a workaround for an older compiler bug. Perhaps it could be
removed now, so there is more space for this one?
Please reconsider.
Thanks,
--
Miroslav Lichvar
>From 150e7c8ed96d078d025f154c219c0a4367a401f
me residual ntp error. Adding xtime_remainder to
timekeeping_bigadjust() fixes that.
I've some comments on the performance of the proposed code, I'll send
them in a separate mail later.
Thanks,
--
Miroslav Lichvar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
->ntp_error >> (NTP_SCALE_SHIFT/2);
> error2 = abs(error2);
> for (look_ahead = 0; error2 > 0; look_ahead++)
> error2 >>= 2;
>
--
Miroslav Lichvar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to m
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 tak
erval*2, so timekeeping_bigadjust() is
called on every update. The bigadjust correction seems too weak to
bring the error down to activate the normal +1/-1 adjustment, the
error keeps increasing and the frequency is slighly off.
What does the following line from your patch mean?
tick_error -=
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
didn't find anything that wouldn't complicate the mult
adjustment logic and bring back the problems which the direct division
approach is supposed to solve.
It seems it may be a while before the old vsyscalls are fixed. How
about including only the first two patches from this set for now?
Thanks,
t; freq10 freq100 dev max
> nohz on 0.00582 0.00033 74.1279.9
> nohz off 0.06275 0.06440 0.4 1.4
--
Miroslav Lichvar
--
To unsubscribe from this list: send the line "unsubscribe linux-kern
On Mon, May 19, 2014 at 10:57:29AM -0700, John Stultz wrote:
> On Mon, May 19, 2014 at 3:14 AM, Miroslav Lichvar wrote:
> > Ok, so it seems to be almost identical to my patch now. The only two
> > differences seem to be the removal of the ntp_error correction to
> > chang
On Tue, Jul 15, 2014 at 09:02:38PM -0700, John Stultz wrote:
> On 07/08/2014 04:08 AM, Miroslav Lichvar wrote:
> > It seems it may be a while before the old vsyscalls are fixed. How
> > about including only the first two patches from this set for now?
>
> Hey! Sorry for the
may fail.
Maybe this test and other tests that measure the frequency of the
system clock should be modified to SKIP when adjtimex() returns a
non-zero offset (or the frequency changes during the test)?
--
Miroslav Lichvar
d init_test(void)
>
> if (precision > MAX_PRECISION) {
> printf("[SKIP]\n");
> - ksft_exit_skip();
> + ksft_exit_skip("[SKIP]\n");
To avoid printing "skip" multiple times, I'd suggest to change the
argument of ksft_exit_skip to NULL.
Thanks,
--
Miroslav Lichvar
eems slightly better in my mind.
Yeah, controlling the clock in such conditions will be difficult. The
kernel/ntp PLL requires periodic updates. There is some code in
ntp_update_offset() that reduces the frequency adjustment when PLL
updates are missing, but I'm not actually sure if it works correctly
with suspend.
--
Miroslav Lichvar
000 3 12 +0.000 4 11 [OK]
Miroslav Lichvar (2):
timekeeping: Don't align frequency adjustments to ticks
timekeeping: Determine multiplier directly from NTP tick length
include/linux/timekeeper_internal.h | 2 +
kernel/time/timekeeping.c |
the point where the frequency is
effectively changed at the time of the update. This removes a major
source of the NTP error.
Cc: John Stultz
Cc: Prarit Bhargava
Cc: Richard Cochran
Signed-off-by: Miroslav Lichvar
---
kernel/time/timekeeping.c | 3 ---
1 file changed, 3 deletions(-)
diff
: Prarit Bhargava
Cc: Richard Cochran
Signed-off-by: Miroslav Lichvar
---
include/linux/timekeeper_internal.h | 2 +
kernel/time/timekeeping.c | 138
2 files changed, 49 insertions(+), 91 deletions(-)
diff --git a/include/linux/timekeeper_internal.h
5 [OK]
10 +0.000 3 12 +0.000 4 11 [OK]
Miroslav Lichvar (2):
timekeeping: Don't align frequency adjustments to ticks
timekeeping: Determine multiplier directly from NTP tick length
include/linux/timekeeper_internal.h | 2 +
kernel/time/timekeepin
1 - 100 of 188 matches
Mail list logo
