Again, sorry for replying so late. I've been mostly offline over the holidays.
Zefram schrieb: > Martin Burnicki wrote: >> https://www.meinberg.de/download/burnicki/ntp_leap_smearing_test_results.pdf > > This is interesting. The smear actually achieved on the downstream ntp > is a complicated function of the smear introduced upstream. Your graphs > nicely illustrate the lesson that Google has imparted recently, that > there's little advantage in a sinusoidal shape for a slow smear. It also > shows that the smear isn't really as successful as one might expect: > the smeared clock isn't being tracked without significant error. Indeed. As expected this depends on the server's smear interval and smear shape, on the client's poll interval, if the server starts smearing just after the client has polled, or shortly before it polls next time, etc. However, my initial motivation to run these time-consuming tests was that I read that some folks thought the could just smear the leap second over 2000 seconds or so, and I didn't believe this works properly with standard NTP clients. > An immediate implication is that, if one needs to recover real UTC > from a timestamp generated on a system downstream of such a smear, then > for precision finer than 100 ms it is not sufficient to just apply the > inverse of the smear that was introduced. As I've already mentioned in another reply, I think this kind of leap smearing is just a hack, an ugly workaround for clients which are seriously affected by leap seconds. For example, we have a customer running an old Linux system with the kernel bug where it just hangs when the leap second is inserted. Even though they know there is a patched kernel available there are some specific reasons why they can't apply any update. So letting the server smear the leap second avoids problems with that machine. I don't think clients of a smearing server should try to undo the smearing. Rather, the time distribution should be set up such that most of the stuff works as usually, without smearing, and smeared time should only be supplied to machines which can't handle leap seconds for some reason. Martin _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs