many of the existing applications it
would break.
--
Miroslav Lichvar
urrently
> executed and has not yet managed to rearm the hrtimer.
>
> Not a big problem as it just schedules work for nothing.
No more unexpected updates of the RTC observed.
Tested-by: Miroslav Lichvar
Thanks,
--
Miroslav Lichvar
On Wed, Dec 02, 2020 at 04:07:28PM +0100, Miroslav Lichvar wrote:
> On Wed, Dec 02, 2020 at 02:44:53PM +0100, Thomas Gleixner wrote:
> > Something like the completely untested below should make this reliable
> > and only needs to retry when the work is running late (busy machin
ime.
Thanks,
--
Miroslav Lichvar
t the counter when the check finally succeeds. This will
allow the RTC update to keep good accuracy if it can happen in the first
few attempts and it will not take more than a minute if the timing is
consistently bad for any reason.
Signed-off-by: Miroslav Lichvar
Cc: Thomas Gleixner
Cc: John S
On Tue, Dec 01, 2020 at 12:12:24PM -0400, Jason Gunthorpe wrote:
> On Tue, Dec 01, 2020 at 03:38:35PM +0100, Miroslav Lichvar wrote:
> > + unsigned long time_set_nsec_fuzz;
> > + static unsigned int attempt;
>
> Adding a static value instide a static inline should not be
nally succeeds. This should allow the RTC update to happen in
a minute at most.
Signed-off-by: Miroslav Lichvar
Cc: Thomas Gleixner
Cc: John Stultz
Cc: Prarit Bhargava
Cc: Jason Gunthorpe
---
include/linux/rtc.h | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --
On Wed, Aug 21, 2019 at 11:53:12AM +0200, Hubert Feurstein wrote:
> Am Mi., 21. Aug. 2019 um 10:07 Uhr schrieb Miroslav Lichvar
> > Because those reports/statistics are important in calculation of
> > maximum error. If someone had a requirement for a clock to be accurate
> >
On Tue, Aug 20, 2019 at 06:56:56PM +0200, Hubert Feurstein wrote:
> Am Di., 20. Aug. 2019 um 17:40 Uhr schrieb Miroslav Lichvar
> > I think a large jitter is ok in this case. We just need to timestamp
> > something that we know for sure happened after the PHC timestamp. It
>
the minimum interrupt delay, I'd still
prefer an overly pessimistic interval assuming a zero delay.
--
Miroslav Lichvar
On Tue, Aug 20, 2019 at 02:29:27PM +0200, Hubert Feurstein wrote:
> Am Di., 20. Aug. 2019 um 11:49 Uhr schrieb Miroslav Lichvar
> > This is important to not break the estimation of maximum error in the
> > measured offset. Applications using the ioctl may assume that the
>
(post_ts-pre_ts)/2 (i.e. half of the delay printed by
phc2sys). That would not work if the delay could be occasionally 50
microseconds for instance, i.e. the post_ts timestamp would be earlier
than the PHC timestamp.
--
Miroslav Lichvar
on't have to change the API, like you did with
> mdiobus_write_nested_ptp. Relatively speaking, this is the least
> amount of intrusion (although, again, far from beautiful).
That would make sense to me, if there are other drivers that could use
it.
> I also added Miroslav Lichvar,
Commit-ID: d21e43f2ef32ba3242687dbedb3c4b9a76b3eebc
Gitweb: https://git.kernel.org/tip/d21e43f2ef32ba3242687dbedb3c4b9a76b3eebc
Author: Miroslav Lichvar
AuthorDate: Tue, 18 Jun 2019 18:06:12 +0200
Committer: Thomas Gleixner
CommitDate: Sat, 22 Jun 2019 11:28:53 +0200
kselftests
Commit-ID: d897a4ab11dc8a9fda50d2eccc081a96a6385998
Gitweb: https://git.kernel.org/tip/d897a4ab11dc8a9fda50d2eccc081a96a6385998
Author: Miroslav Lichvar
AuthorDate: Tue, 18 Jun 2019 17:47:13 +0200
Committer: Thomas Gleixner
CommitDate: Sat, 22 Jun 2019 11:28:53 +0200
ntp: Limit TAI
yd
Signed-off-by: Miroslav Lichvar
---
tools/testing/selftests/timers/freq-step.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/timers/freq-step.c
b/tools/testing/selftests/timers/freq-step.c
index 8cd10662ffba..4b76450d78d1 100644
--- a/too
n
Cc: Stephen Boyd
Cc: Thomas Gleixner
Signed-off-by: Miroslav Lichvar
---
kernel/time/ntp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index 8de4f789dc1b..65eb796610dc 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@
aybe it would make sense to
specify a much smaller maximum like 100?
Even 1000 should be good enough for near future. Negative values are
not allowed anyway. If the Earth's rotation changed significantly
(e.g. hitting a very large asteroid), there probably wouldn't be
anyone left to care about TAI.
--
Miroslav Lichvar
Commit-ID: fdc6bae940ee9eb869e493990540098b8c0fd6ab
Gitweb: https://git.kernel.org/tip/fdc6bae940ee9eb869e493990540098b8c0fd6ab
Author: Miroslav Lichvar
AuthorDate: Wed, 17 Apr 2019 10:48:33 +0200
Committer: Thomas Gleixner
CommitDate: Thu, 9 May 2019 10:46:58 +0200
ntp: Allow TAI-UTC
On Wed, Apr 17, 2019 at 11:00:23AM +0200, Ondrej Mosnacek wrote:
> On Wed, Apr 17, 2019 at 10:48 AM Miroslav Lichvar wrote:
> > Change the ADJ_TAI check to accept zero as a valid TAI-UTC offset in
> > order to allow setting it back to the initial value.
> Thanks for sending th
t Bhargava
Suggested-by: Ondrej Mosnacek
Signed-off-by: Miroslav Lichvar
---
kernel/time/ntp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index 92a90014a925..f43d47c8c3b6 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -69
constant > 0?
I guess zero here means "unknown" and maybe the intention was to not
allow setting the offset to an unknown value once it has been set to a
valid value. The trouble is that after inserting a leap second the
offset may change from zero to one.
I think it should be changed to allow setting the offset to zero.
--
Miroslav Lichvar
ght possibly
break more tests (or any unusual applications messing with time) as a
much larger interval is now EINVAL.
Thanks,
--
Miroslav Lichvar
ime itself. ktime_t
overflows on Apr 11 2262. clock_settime() and adjtimex(ADJ_SETOFFSET)
can set the time close to the overflow and let everything break.
Boot a VM and try this:
# date -s 'Apr 11 23:47:15 UTC 2262'
There was a patch submitted couple years ago that prevented overflows
i
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
> > -&g
hich 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 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
&
e.g. due to unsynchronized 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
}
> printf(" [FAILED]\n");
> return ksft_exit_fail();
> }
> --
> 2.7.4
>
--
Miroslav Lichvar
"ADJ_OFFSET 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
tight 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:
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
tight 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 timekeepe
On Wed, May 23, 2018 at 11:05:34AM -0700, John Stultz wrote:
> On Wed, May 23, 2018 at 4:33 AM, Miroslav Lichvar wrote:
> > This removes a hidden non-deterministic delay in setting of the
> > frequency and allows an extremely tight control of the system clock
> > with upd
tight 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
---
kernel/time/timekeeping.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff
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
yd
Signed-off-by: Miroslav Lichvar
---
tools/testing/selftests/timers/freq-step.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/timers/freq-step.c
b/tools/testing/selftests/timers/freq-step.c
index 14a2b77fd012..cd094b49819f 100644
--- a/too
Commit-ID: 78b98e3c5a66d569a53b8f57b6a698f912794a43
Gitweb: https://git.kernel.org/tip/78b98e3c5a66d569a53b8f57b6a698f912794a43
Author: Miroslav Lichvar
AuthorDate: Fri, 9 Mar 2018 10:42:48 -0800
Committer: Ingo Molnar
CommitDate: Sat, 10 Mar 2018 09:12:41 +0100
timekeeping/ntp
Commit-ID: c2cda2a5bda9f1369c9d1ab54a20571c13cf2743
Gitweb: https://git.kernel.org/tip/c2cda2a5bda9f1369c9d1ab54a20571c13cf2743
Author: Miroslav Lichvar
AuthorDate: Fri, 9 Mar 2018 10:42:47 -0800
Committer: Ingo Molnar
CommitDate: Sat, 10 Mar 2018 09:12:41 +0100
timekeeping/ntp: Don&#
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/timek
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
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
Commit-ID: aea3706cfc4d952ed6d32b6d5845b5ecd99ed7f5
Gitweb: https://git.kernel.org/tip/aea3706cfc4d952ed6d32b6d5845b5ecd99ed7f5
Author: Miroslav Lichvar
AuthorDate: Mon, 13 Nov 2017 14:51:31 -0800
Committer: Thomas Gleixner
CommitDate: Tue, 14 Nov 2017 11:20:25 +0100
timekeeping
nd 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
| 240 |
>
> Using so_txtime, the peak to peak jitter is about 100 nanoseconds,
Nice!
--
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
Cochran
Signed-off-by: Miroslav Lichvar
---
tools/testing/selftests/timers/inconsistency-check.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/timers/inconsistency-check.c
b/tools/testing/selftests/timers/inconsistency-check.c
index caf1bc9
sue for 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
exceed specified limits.
Cc: John Stultz
Cc: Richard Cochran
Cc: Prarit Bhargava
Signed-off-by: Miroslav Lichvar
---
tools/testing/selftests/timers/Makefile| 5 +-
tools/testing/selftests/timers/freq-step.c | 268 +
2 files changed, 271 insertions(+), 2 deletions
On Fri, May 19, 2017 at 05:35:38PM -0700, John Stultz wrote:
> >> On Wed, May 17, 2017 at 10:22 AM, Miroslav Lichvar
> >> wrote:
> >> > Is there a better way to run the timekeeping code in an userspace
> >> > application? I suspect it would need some
On Wed, May 17, 2017 at 10:02:00AM -0700, John Stultz wrote:
> On Wed, May 17, 2017 at 9:57 AM, Miroslav Lichvar wrote:
> > On Wed, May 17, 2017 at 09:30:31AM -0700, John Stultz wrote:
> >> Could you submit your linux-tktest infrastructure to the kselftests dir?
> >
&g
mess that breaks frequently as the timekeeping and
other kernel code changes. Are you sure you want that in the kernel
tree? :)
--
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
Cc: Prarit Bhargava
Cc: Richard Cochran
Signed-off-by: Miroslav Lichvar
---
include/linux/timekeeper_internal.h | 7 --
kernel/time/Kconfig
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
Cc: Prarit Bhargava
Cc: Richard Cochran
Signed-off-by: Miroslav Lichvar
---
kernel/time/timekeeping.c | 3 ---
1 file changed, 3 deletions(-)
diff
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
: Prarit Bhargava
Cc: Richard Cochran
Signed-off-by: Miroslav Lichvar
---
include/linux/timekeeper_internal.h | 2 +
kernel/time/timekeeping.c | 137
2 files changed, 48 insertions(+), 91 deletions(-)
diff --git a/include/linux/timekeeper_internal.h
On Fri, May 12, 2017 at 10:26:12AM -0700, John Stultz wrote:
> On Fri, May 12, 2017 at 8:14 AM, Miroslav Lichvar wrote:
> > I see this with real PHCs and PTP/NTP synchronization too. It's very
> > confusing when the timekeeping changes so much for no apparent reason.
> &
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
> >
quot;
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
PTP using two
NICs with HW timestamping.
--
Miroslav Lichvar
_PRECISE may assume the
conversion 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
ts[3]
Host time-+-+
| |
| |
Guest time +-+-+..
ts[0]ts[2] ts[4]
--
Miroslav Lichvar
o 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: Miro
check could 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
;
> /* 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/
lock back 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
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 includ
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
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
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 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 t
Signed-off-by: Miroslav Lichvar
---
v2: - optimized code in accumulate_nsecs_to_secs() a bit
- improved log message and increased its level to warning
Documentation/sysctl/kernel.txt | 19
include/linux/timekeeping.h | 5
include/uapi/linux/sysctl.h | 1 +
On Thu, Sep 10, 2015 at 11:14:25AM -0700, John Stultz wrote:
> On Thu, Sep 10, 2015 at 10:42 AM, John Stultz wrote:
> > On Thu, Sep 10, 2015 at 5:02 AM, Miroslav Lichvar
> > wrote:
> >> The precision of the clock is better than microsecond, so that
> >> wouldn&
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
off
is not 100 on all archs.
> + for (tick = 9000; tick < 11000; tick += 250)
> + if (check_tick_adj(tick)) {
This too.
> + tx1.tick = 1;
> + adjtimex(&tx1);
And this too.
--
Miroslav Lichvar
--
To unsubscribe from this list: send the line "unsubscribe
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() {
lse. 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 like to try to reproduce the
ep = time_max_sec - tk->xtime_sec - SEC_PER_WEEK;
> > + printk(KERN_NOTICE
> > + "Clock: maximum time reached, stepping
> > back\n");
> > + }
> > +
> > + if (unlikely(step)) {
> >
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 wrote:
> > larger value. When the maximum is reached in normal time accumulation,
> > the clock will be stepped back by one week.
>
> Which itself
2 for one week 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
---
Documentation/sysctl/
ions for the overflow.
What do you 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 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
*/
Shouldn't be time_status reset and the PPS calibration restarted even
when state is TIME_OOP?
--
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 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
rounding, but I 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 thi
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
> $ ./test1.sh
> 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 &qu
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 to use more points
I can see it does converge to the correct frequency and probably it's
not a big problem.
It seems 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
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 test
mizations were made, but that division is still used in 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,
--
Miros
o converge to the correct frequency, but
there is some 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
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 le
above interval*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?
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 i
Z);
> + error2 = tk->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
1 - 100 of 106 matches
Mail list logo
