Re: [chrony-dev] [GIT] chrony/chrony.git branch, master, updated. 2.0-13-g0abdc2a

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Tue, Jun 02, 2015 at 07:48:48AM -0700, Bill Unruh wrote:
> It really would be nice if Mill's leap clock stop were really implimented
> instead of the backward step the kernel does now (I had thought that it was
> implimented. I was wrong)

If you are refering to the approach where the clock is "stopped" and
is advanced only when something reads the clock, I think that would be
difficult to implemented in modern kernels since the reading of the
clock doesn't involve a system call and the kernel doesn't really know
if there are any processes reading the clock.

Anyway, I think a clock having a frequency error of 99.99% (running
10000x slower) would be more problematic for applications than 8.3% as
for instance chrony uses in the slew mode by default. The interval
where the clock is wrong would be only 12 times shorter (1.0001 second
vs 12 seconds).

> Alternatively  the system clock uses  TAI seconds, and the conversion to UTC
> happened in the gettime software, since it already has to handle conversion to
> YMDHMS anyway. Of course this would mean that ntp would need a flag to tell
> that it was on TAI rather than UTC seconds or clients would again get
> confused.

NTP clients could convert UTC to TAI locally using system tzdata (e.g.
with the right/UTC timezone). The problem is with applications that
rely on the POSIX definition of system time where every day has 86400
seconds.

The Linux kernel provides the CLOCK_TAI clock which doesn't have the
backward step, but we can probably safely assume only a small minority
of applications will be modified to use that.

This whole problem with handling leap seconds is about breaking as few
applications running on the system as possible.

-- 
Miroslav Lichvar

-- 
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.