[ntp:hackers] ITU and Leap second elimination

juergen perlinger juergen.perlinger at t-online.de
Fri Oct 4 16:51:25 UTC 2013


On 10/04/2013 10:03 AM, Miroslav Lichvar wrote:
> On Thu, Oct 03, 2013 at 02:36:49PM -0700, John Stultz wrote:
>> But due to performance concerns (CLOCK_REALTIME is what applications
>> hammer the most), in Linux we actually structure it as:
>>
>> CLOCK_REALTIME: Initialized at boot from RTC
>> CLOCK_MONOTONIC: CLOCK_REALTIME - wall_to_monotonic
>> CLOCK_TAI: CLOCK_REALTIME + tai_offset
>>
>> Where wall_to_monotonic is set to the negative of what we initialize
>> time as (and then adjusted any time do_settimeofday is called).
> I'm wondering, how feasible it would be to have two (or three)
> separate clocks for CLOCK_MONOTONIC and CLOCK_REALTIME/CLOCK_TAI
> instead of keeping them at a fixed offset from each other?
>
> I think the CLOCK_MONOTONIC users care only about frequency accuracy
> and the CLOCK_REALTIME users care mostly about time accuracy. If the
> two clocks were decoupled, wouldn't it be easier to apply the leap
> second to CLOCK_REALTIME by slewing without disturbing CLOCK_MONOTONIC?
> It would possibly allow also other nice thing, like improving the
> frequency accuracy of CLOCK_MONOTONIC by not including the PLL phase
> adjustments to it.
>
Linux has CLOCK_MONOTONIC_RAW for that. I start to get mixed feelings
about the direction this is going to :-/

I think we should get our target straight. When we fear there are too
many time scales around, we should not create our own, unless there is
dire need. If a raw monotonic clock without FLL/PLL corrections is
something that happens on the fly, ok. I can imagine use for that in the
FLL/PLL code, but I'm not sure it's useful on API level.

CLOCK_MONOTONIC and CLOCK_TAI are both frequency adjusted, to keep as
close to a SI second as the system permits. I guess you want
CLOCK_MONTONIC to be only FLL adjusted, because there is no need for a
fixed phase relation to CLOCK_TAI anyway. IMHO this is an error. It lets
adjustment errors creep uncontrolled into CLOCK_MONOTONIC, while
CLOCK_TAI controls the accumulated error via the PLL. Then the elapsed
time between two events will depend on the clock you use, and I think
that's evil. We have something similar already.

CLOCK_REALTIME can be created from CLOCK_TAI by the use of a transition
table.

If we really want to smear/disperse the leap second into the UTC time
scale, it can be done by a linear interpolation over the transition,
without affecting the PLL/FLL adjustments. One closed loop is enough to
handle. Having one that hops along happily and another one that is
seriously skewed sometimes sounds like a solid nightmare to me.

And are we sure that the leap second smear is something we really need?
Or is it just an artifact from an attempt to gloss over the problems the
current representation of UTC suffers over a radix change, aka leap
second? Is it still needed in the light of having CLOCK_MONOTONIC and
CLOCK_TAI?

NTPD could be tuned in a way that makes sure that time stamps involved
in arithmetic operations are always on the same side of a leap
transition, and mixed operations woul be considered invalid. This would
perhaps throw away information during two seconds, but hey, this is UDP!
We could have a message loss anyway, anytime.

Cheers,
    J



More information about the hackers mailing list