Steve Summit wrote: > Martin Burnicki wrote: >> IMO another clock type to be used with clock_gettime() would help, as >> already proposed by Markus Kuhn (there was a link to this in a recent >> post here), which could be used by new or actively maintained software. > > Sure. (But are you talking about CLOCK_UTC, or yet another new id?) > At any rate, yes, ntpd is certainly a fine candidate for being > modified to use clock_gettime and special clockids.
I have no particular ID in mind. Generally there are 2 ways: 1.) You could leave the existing API with CLOCK_REALTIME unchanged, and introduce a new clock ID to return "smeared" time, or ... 2.) You could change the existing API to let CLOCK_REALTIME return "smeared" time, and introduce a new clock ID (e.g. "CLOCK_UTC") to return "true" UTC time (whatever "true" means for timestamps taken during a leap second). Both approaches will probably cause unexpected behavior for certain applications, but my feeling is that if you implement the 2nd approach then at first the time synchronization software needs to be modified to use the new API, while most existing applications wouldn't even notice that CLOCK_REALTIME behaves differently, except that they don't observe a timestep back when a leap second is inserted. 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. Currently the TAI/UTC offset is transmitted by the PTP protocol, ntpd passes the TAI offset to the kernel if the offset is known, e.g. from a leap second file, or from TAI information transferred by NTP's autokey extensions. BTW, autokey is going to be obsoleted and replaced by the new Network Time Security (NTS) protocol extension, so there should be a new extension field defined for NTP to be able to transmit the TAI offset. > (I went down the road I did because one of my secondary goals was > to rig things up so that you could successfully use a modified -- > fully UTC-aware -- kernel along with an unmodified ntpd. At > first I was thinking of having the smearing scheme be adjustable > on a per-process basis, with ntpd's process getting 'unsmeared' > even for CLOCK_REALTIME. But then I realized that since ntp -- > I thought -- used adjtime for everything, I could use the trick > I described. Oh, well.) Yes, see my other reply to Zefram, and my thoughts on SO_TIMESTAMP and friends. Martin _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs