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. 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. One must also model the error introduced by the difficulty of the unaware downstream ntp in tracking the smear. I would be interested to see how consistent the tracking error is across multiple runs of this scenario, and with varying phase of the polling cycle. The level of consistency here places an upper limit on how precisely UTC can be recovered from the smeared timestamps, in the usual case where the tracking error wasn't measured at the time. NTP's multi-stratum architecture means that this problem isn't limited to the simple case of tracking a clock that is smearing cleanly. The unaware ntp doing that may also serve as the reference for a further-downstream client, which then has the even more difficult job of tracking an uncleanly-smearing clock. I'd like to see how the tracking error changes with stratum. To recover UTC, one would need to know by how many NTP links the timestamping system is removed from the system introducing the smear, in order to correctly model the tracking error. To make analysis easier, it would be tempting to look for a smear shape that is an eigenvalue of the clock tracking function. But I think there can't be such a shape: an unaware client by definition can't start its own frequency shift until strictly after its upstream reference has started it. I think the complications of multi-stratum tracking are just going to be managed by avoiding having more than a couple of layers. But an understanding of the imperfect clock tracking opens up another possibility: could a sufficiently clever ntp server introduce a smear calculated to manipulate its clients into actually executing a smear of a precisely specified target shape? Presumably this would require starting the smear early, exaggerating the frequency offset at the start, and temporarily overshooting the return to normal frequency at the end. This could get us an easily-inverted linear smear on unaware timestamp-generating clients. A final lesson to draw here is that lying about the time is a problematic strategy. The smear is not a great way to steer a clock that doesn't know that a smear is going on. The smear *is* good for squeezing UTC into timestamp data formats that can't handle 23:59:60, provided that no precise computation needs to be performed by an unaware entity. So the better way to implement the smear would be to shift it downstream: clock synchronisation should be all unadulterated NTP handling the leap as a leap, and the lying should happen later, probably where the client ntp instances are steering their system clock. -zefram _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
