3 ms·
Imho that's no better. A leap second "smears" the day lengths. Smearing the leap second means introducing changes at some scale, eg. more or less micro- or nano
by chopin 8y ago
Imho that's no better. A leap second "smears" the day lengths. Smearing the leap second means introducing changes at some scale, eg. more or less micro- or nanoseconds. Software needs ro be able to cope with this.
- rkagerer 8y agoI had the same thought but... The smear technique results in seconds that are 11.6μs longer than nominal, and Google makes the case this is within the "manufacturing and thermal errors of most machines' quartz oscillators". So at face value, I'd say software already copes with discrepancies of that order. However I would infer the maximum delta actually seen by an NTP client is larger and depends on the client's polling interval. e.g. If a machine runs a normal clock locally and synchronizes every 20 minutes (which is probably on the high side), it would see about a 14ms jump on each sync during the 24 hour smear window. That's assuming the NTP client doesn't already use a smear algorithm locally to correct for drift (Windows doesn't, but I think Red Hat Linux might? Per https://access.redhat.com/solutions/39194 https://access.redhat.com/solutions/39194 "NTP polling does not directly synchronize the local system clock to the server clock; rather, a complex algorithm calculates an adjustment value for each tick of the local system clock") Maybe someone more well-versed can elaborate further.