On Fri, Mar 26, 2021 at 08:28:59PM -0700, Richard Cochran wrote: > Using ntpd on Debian, the service will set the offset, but only after > synchronization with the upstream server has been established, and > this takes about five minutes, IIRC.
With the iburst option it shouldn't take more than 10 seconds. There might be an issue wrt stepping the clock when the initial offset is large. In Fedora and derived distros using chrony by default the TAI-UTC offset should be set right on the first update of the clock as expected. > Getting back to the original point of the kernel returning an error, > I don't see a need for this. Applications that require correct leap > seconds can simply call adjtimex() and wait until the initial zero > value is changed by ntpd/etc to the correct offset. That isn't > fundamentally harder than calling clock_gettime() and waiting until > the error would go away. There are at least two issues with handling a zero offset as a special value. One is that zero could potentially be a valid value in distant future. The other is that the kernel updates the offset when a leap second is inserted/deleted even if the original offset is zero, so checking for zero (in the kernel or an application) works only until the first leap second after boot. The kernel would need to set a flag that the offset was set. Returning an error in clock_gettime() until the offset is set sounds reasonable to me, but I have no idea how many of the existing applications it would break. -- Miroslav Lichvar
