Re: TSC to Mono-raw Drift

2018-11-02 Thread Miroslav Lichvar
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 > >

Re: TSC to Mono-raw Drift

2018-11-02 Thread Miroslav Lichvar
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

Re: TSC to Mono-raw Drift

2018-11-02 Thread 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

Re: TSC to Mono-raw Drift

2018-10-25 Thread 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 &

Re: TSC to Mono-raw Drift

2018-10-24 Thread Miroslav Lichvar
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

Re: [RFC][PATCH v2] selftest: timers: Tweak raw_skew to SKIP when ADJ_OFFSET/other clock adjustments are in progress

2018-07-09 Thread Miroslav Lichvar
} > printf("[FAILED]\n"); > return ksft_exit_fail(); > } > -- > 2.7.4 > -- Miroslav Lichvar

Re: [RFC][PATCH] selftest: timers: Tweak raw_skew to SKIP when ADJ_OFFSET is in progress

2018-07-04 Thread Miroslav Lichvar
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

[PATCHv2] timekeeping: Update multiplier when NTP frequency is set directly

2018-06-04 Thread Miroslav Lichvar
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

Re: [PATCHv1] timekeeping: Update multiplier when NTP frequency is set directly

2018-06-04 Thread Miroslav Lichvar
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

[PATCHv1] timekeeping: Update multiplier when NTP frequency is set directly

2018-05-29 Thread Miroslav Lichvar
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

Re: [PATCH RFC] timekeeping: Update multiplier when NTP frequency is set directly

2018-05-24 Thread Miroslav Lichvar
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

[PATCH RFC] timekeeping: Update multiplier when NTP frequency is set directly

2018-05-23 Thread 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:

Re: possible BUG: selftest about raw_skew failed

2018-04-27 Thread 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

[PATCH] kselftests: timers: freq-step: Update maximum acceptable precision and errors

2018-04-10 Thread 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(

[tip:timers/core] timekeeping/ntp: Determine the multiplier directly from NTP tick length

2018-03-10 Thread tip-bot for Miroslav Lichvar
Commit-ID: 78b98e3c5a66d569a53b8f57b6a698f912794a43 Gitweb: https://git.kernel.org/tip/78b98e3c5a66d569a53b8f57b6a698f912794a43 Author: Miroslav Lichvar <mlich...@redhat.com> AuthorDate: Fri, 9 Mar 2018 10:42:48 -0800 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Sat,

[tip:timers/core] timekeeping/ntp: Don't align NTP frequency adjustments to ticks

2018-03-10 Thread tip-bot for Miroslav Lichvar
Commit-ID: c2cda2a5bda9f1369c9d1ab54a20571c13cf2743 Gitweb: https://git.kernel.org/tip/c2cda2a5bda9f1369c9d1ab54a20571c13cf2743 Author: Miroslav Lichvar <mlich...@redhat.com> AuthorDate: Fri, 9 Mar 2018 10:42:47 -0800 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Sat,

[PATCHv2 0/2] Improve stability of system clock

2018-01-05 Thread Miroslav Lichvar
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

[PATCHv2 1/2] timekeeping: Don't align frequency adjustments to ticks

2018-01-05 Thread Miroslav Lichvar
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

[PATCHv2 2/2] timekeeping: Determine multiplier directly from NTP tick length

2018-01-05 Thread 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 | 138 -

[PATCHv2 0/2] Improve stability of system clock

2018-01-05 Thread 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 |

[tip:timers/urgent] timekeeping: Remove CONFIG_GENERIC_TIME_VSYSCALL_OLD

2017-11-14 Thread tip-bot for Miroslav Lichvar
Commit-ID: aea3706cfc4d952ed6d32b6d5845b5ecd99ed7f5 Gitweb: https://git.kernel.org/tip/aea3706cfc4d952ed6d32b6d5845b5ecd99ed7f5 Author: Miroslav Lichvar <mlich...@redhat.com> AuthorDate: Mon, 13 Nov 2017 14:51:31 -0800 Committer: Thomas Gleixner <t...@linutronix.de> CommitD

Re: Extreme time jitter with suspend/resume cycles

2017-10-05 Thread 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

Re: [PATCH RFC V1 net-next 0/6] Time based packet transmission

2017-09-19 Thread Miroslav Lichvar
240 | > > Using so_txtime, the peak to peak jitter is about 100 nanoseconds, Nice! -- Miroslav Lichvar

Re: [RFC][PATCH 2/2] selftests: timers: freq-step: Fix build warning

2017-08-15 Thread 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

Re: [PATCH] kselftest/timers: fix build failure

2017-07-25 Thread 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

[PATCH] kselftests: timers: Fix inconsistency-check to not ignore first timestamp

2017-06-13 Thread 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/

Re: [PATCH 2/3 v3] time: Fix CLOCK_MONOTONIC_RAW sub-nanosecond accounting

2017-06-13 Thread Miroslav Lichvar
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

[PATCH] kselftests: timers: Add test for frequency step

2017-06-09 Thread Miroslav Lichvar
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

Re: [PATCH RFC 0/3] Improve stability of system clock

2017-06-08 Thread Miroslav Lichvar
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?

Re: [PATCH RFC 0/3] Improve stability of system clock

2017-05-17 Thread Miroslav Lichvar
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

Re: [PATCH RFC 0/3] Improve stability of system clock

2017-05-17 Thread Miroslav Lichvar
that breaks frequently as the timekeeping and other kernel code changes. Are you sure you want that in the kernel tree? :) -- Miroslav Lichvar

[PATCH RFC 1/3] timekeeping: Remove support for old vsyscalls

2017-05-17 Thread Miroslav Lichvar
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

[PATCH RFC 2/3] timekeeping: Don't align frequency adjustments to ticks

2017-05-17 Thread Miroslav Lichvar
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

[PATCH RFC 0/3] Improve stability of system clock

2017-05-17 Thread Miroslav Lichvar
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

[PATCH RFC 3/3] timekeeping: Determine multiplier directly from NTP tick length

2017-05-17 Thread 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 -

Re: [PATCH 0/3] timekeeping: Improved NOHZ frequency steering (v2)

2017-05-17 Thread 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

Re: [PATCH 0/3] timekeeping: Improved NOHZ frequency steering (v2)

2017-05-12 Thread Miroslav Lichvar
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

Re: [patch 4/5] PTP: add PTP_SYS_OFFSET emulation via cross timestamps infrastructure

2017-01-24 Thread Miroslav Lichvar
option to not use the PRECISE ioctl even if it's supported. -- Miroslav Lichvar

Re: [patch 4/5] PTP: add PTP_SYS_OFFSET emulation via cross timestamps infrastructure

2017-01-20 Thread 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

Re: [patch 3/3] PTP: add kvm PTP driver

2017-01-18 Thread Miroslav Lichvar
two NICs with HW timestamping. -- Miroslav Lichvar

Re: [patch 3/3] PTP: add kvm PTP driver

2017-01-18 Thread 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

Re: [patch 3/3] PTP: add kvm PTP driver

2017-01-17 Thread Miroslav Lichvar
+-+ | | | | Guest time +-+-+.. ts[0]ts[2] ts[4] -- Miroslav Lichvar

Re: [RFC][PATCH v3] timekeeping: Cap adjustments so they don't exceed the maxadj value

2015-12-16 Thread Miroslav Lichvar
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

Re: [RFC][PATCH v2] timekeeping: Cap adjustments so they don't exceed the maxadj value

2015-12-14 Thread Miroslav Lichvar
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

Re: [RFC][PATCH] timekeeping: Cap adjustments so they don't exceede the maxadj value

2015-12-07 Thread Miroslav Lichvar
/* 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/

Re: [RESEND PATCH] timerfd: Allow TFD_TIMER_CANCEL_ON_SET with relative timeouts

2015-10-20 Thread Miroslav Lichvar
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

Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-10-09 Thread Miroslav Lichvar
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

Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-10-09 Thread Miroslav Lichvar
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

Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-10-08 Thread Miroslav Lichvar
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

Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-10-08 Thread Miroslav Lichvar
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

[PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-10-07 Thread Miroslav Lichvar
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

Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-10-07 Thread Miroslav Lichvar
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 &

Re: [PATCH 2/2 (v2)] kselftest: timers: Add adjtick test to validate adjtimex() tick adjustments

2015-09-14 Thread Miroslav Lichvar
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

Re: [PATCH 2/2 (v2)] kselftest: timers: Add adjtick test to validate adjtimex() tick adjustments

2015-09-10 Thread Miroslav Lichvar
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

Re: [PATCH 2/2][RFC] kselftest: timers: Add adjtick test to validate adjtimex() tick adjustments

2015-09-09 Thread Miroslav Lichvar
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

Re: Regression: can't apply frequency offsets above 1000ppm.

2015-09-03 Thread Miroslav Lichvar
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() {

Re: Regression: can't apply frequency offsets above 1000ppm.

2015-09-02 Thread Miroslav Lichvar
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

Re: [RFC][PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-04-16 Thread Miroslav Lichvar
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

Re: [RFC][PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-04-16 Thread Miroslav Lichvar
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

[RFC][PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

2015-04-15 Thread Miroslav Lichvar
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

Preventing 32-bit time_t overflow

2015-04-09 Thread Miroslav Lichvar
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/

Re: [PATCH] time, ntp: Do not update time_state in middle of leap

2015-02-06 Thread Miroslav Lichvar
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

Re: [PATCH] time, ntp: Do not update time_state in middle of leap

2015-02-04 Thread Miroslav Lichvar
-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

Re: [PATCH 0/3] timekeeping: Improved NOHZ frequency steering (v2)

2014-07-16 Thread Miroslav Lichvar
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

Re: [PATCH 0/3] timekeeping: Improved NOHZ frequency steering (v2)

2014-07-08 Thread Miroslav Lichvar
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

Re: [PATCH 0/3] timekeeping: Improved NOHZ frequency steering (v2)

2014-05-20 Thread Miroslav Lichvar
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

Re: [PATCH 0/3] timekeeping: Improved NOHZ frequency steering (v2)

2014-05-19 Thread Miroslav Lichvar
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

Re: [PATCH 0/3] timekeeping: Improved NOHZ frequency steering

2014-04-30 Thread Miroslav Lichvar
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

Re: [PATCH 0/3] timekeeping: Improved NOHZ frequency steering

2014-04-25 Thread Miroslav Lichvar
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

Re: [PATCH] [RFC] timekeeping: Rework frequency adjustments to work better w/ nohz

2014-04-24 Thread Miroslav Lichvar
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

Re: [PATCH] [RFC] timekeeping: Rework frequency adjustments to work better w/ nohz

2014-02-12 Thread Miroslav Lichvar
. 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

Re: [PATCH] [RFC] timekeeping: Rework frequency adjustments to work better w/ nohz

2014-02-07 Thread Miroslav Lichvar
() 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

Re: [PATCH RFC] timekeeping: Fix clock stability with nohz

2013-12-10 Thread Miroslav Lichvar
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

Re: [PATCH RFC] timekeeping: Fix clock stability with nohz

2013-12-10 Thread 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

Re: [PATCH RFC] timekeeping: Fix clock stability with nohz

2013-12-06 Thread Miroslav Lichvar
; 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/

Re: [PATCH RFC] timekeeping: Fix clock stability with nohz

2013-12-06 Thread Miroslav Lichvar
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

Re: [PATCH RFC] timekeeping: Fix clock stability with nohz

2013-11-21 Thread Miroslav Lichvar
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/

Re: [PATCH RFC] timekeeping: Fix clock stability with nohz

2013-11-20 Thread Miroslav Lichvar
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

[PATCH RFC] timekeeping: Fix clock stability with nohz

2013-11-14 Thread Miroslav Lichvar
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

[PATCH] ntp: Make periodic RTC update more reliable

2013-08-01 Thread Miroslav Lichvar
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

[PATCHv2] posix-timers: Fix clock_adjtime to always return timex data on success

2013-01-11 Thread Miroslav Lichvar
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

[PATCH] posix-timers: Fix clock_adjtime to return timex data on success

2013-01-10 Thread Miroslav Lichvar
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