Martin Burnicki wrote: > If we don't look only at the kernel and ntpd, but also consider PTP, > then there's still the question if if wouldn't be better to let the > kernel time run on TAI, and derive true and/or smeared UTC from it.
Right. At first when I was trying to implement CLOCK_UTC, I lumped it in with the problem of reworking the kernel's internal clock, but actually, they're separate problems. Although I *have* reworked the kernel's internal clock (Linux calls it 'xtime'), it's expensive, and I'm now considering it among other options, of which there are at least three: 1. Have xtime keep true UTC, as I've been doing so far. This was always my first choice, but it ends up being majorly invasive, and I fear the Linux kernel developers will lynch me if I so much as mention it. 2. Have xtime keep TAI. This has the advantage that it's not at all wrong or kludgey to represent TAI as a simple count of seconds since the epoch, which of course xtime already is. The objection, as mentioned here pretty regularly, is that if you want to be able to set the clock from UTC, and deliver UTC, you always need to know TAI-UTC, so if you don't have it (if you're not on the net, or if you don't faithfully receive it early enough during boot) you're sunk. But I'm now thinking that the work involved in assuming TAI-UTC=0 in that case (and remembering that we can't, for example, return success if someone asks for clock_gettime(CLOCK_TAI), and remembering to fiddle things if we learn TAI-UTC later) may end up being less than the work involved in #1. 3. Keep xtime just about the way it is, augmented with a well-defined leap-second flag (along the lines of the TIME_OOP flag returned by adjtimex) so that CLOCK_UTC can still be derived from it with full accuracy. Number 1 was my strong preference at first, because I very much wanted a kernel that kept "true UTC" internally, with no kludges or circumlocutions, and derived everything else from it as necessary. But the implementation cost to achieve that wish is turning out to be very high, so #2 (and even the philosophically ghastly but nicely expedient #3) are starting to look more attractive. _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
