Martin Burnicki wrote: > Steve Summit wrote: > > The answer is that on a system with the mods installed, #1 > > happens all the time for the system calls time(), gettimeofday(), > > and clock_gettime(CLOCK_REALTIME). It does not happen for > > adjtimex, on the assumption that that's what ntpd is using. > > #2 happens only when you call clock_gettime(CLOCK_UTC). > > Unfortunately the assumption that ntpd uses adjtimex() to compute the > current time offset is wrong, as far as I have seen. See my other post.
Yes, I noticed. Thanks. > So if the system calls gettimeofday() and clock_gettime(CLOCK_REALTIME) > return smeared time then ntpd also sees smeared time. Right. Which would completely undermine its clock disciplining algorithm. > 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 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.) _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
