Hi Les, > Interesting, but I thought that ntp clients always advanced the clock > by small fractions of a second anyway even when the master source > differs by more. they do. But the leap second is quite a different thing: Actually the time doesn't really diverge from the server's, but the stratum 1 server deliveres a totally unexpected 01:59:60, and the stratum 2 server follows. The Google approach is not to use that time at all, but slow the clock down a bit on the stratum 2 server so that the stratum 1 (that has the 'genuine' time and jumps to the :60 time stamp after :59) is, after the time window is over, about one second ahead of the stratum 2. So approximately the instant when the stratum 1 server jumps from :59 to :60, the stratum 2 server jumps from :58 to :59, and at the next second tick, they will both jump to 02:00:00 and be in synch again. The same approach works with a negative leap second, which was never needed yet, however. The disadvantage of this method is that you have to know in advance when the leap second will happen, which requires tables that regularly have to be updated since it is fairly unpredictable in the long run when a leap second will be necessary. I don't know why they didn't simply use the 'LI' bit in the NTP protocol to determine when to start 'smearing' - at least the article doesn't say they did: <http://www.networksorcery.com/enp/protocol/ntp.htm> Maybe 24 hours notification in advance did not seem long enough for the smear interval. I doubt it, because I would not really like the time to differ from the real time for more than a day. Best regards, Peter.