[ntp:questions] NTP makes a time jump

unruh unruh at invalid.ca
Mon Jul 8 15:46:25 UTC 2013

On 2013-07-08, Rob <nomail at example.com> wrote:
> karpekin at gmail.com <karpekin at gmail.com> wrote:
>> Hello,
>> Thanks for the answers!
>> The reason of such a configuration is simple. Our equipment is a mission-critical set of devices that shall be running without NTP server available. Some drift away from a true time is tolerable. However, all devices must be synched with each other, to a max of 50ms. That's why I have as a fallback - "if no NTP server available, give devices at least your wrong timestamp and get all synched with it". 
>> The 3 sec drift I set just to emulate the behavior of our "floating NTP island" for example after 2 years of no upsync. And the fact the time made a jump as soon as true server appeared, makes all the devices to jump, but not at the same time due to polling rates, causing all the devices to loose synch for at least max polling time. The ideal behavior I would like to reach is that the server will start to correct the time, slowly coming to the "real" NTP time.
> In what kind of environment can there be a requirement of 50ms time
> synchronization, but a sufficiently sloppy monitoring to allow two years
> without external sync?
> Would it be possible within your budget and installation environment
> to have another time reference, e.g. a receiver for a time signal or a
> GPS receiver?

By the way, even with a slew, since the natural slew rates of various
clocks is different, when they peg out at 500PPM for 8 hours, remember
that some have different natural rate offsets than others. Thus each of
the clocks will slew at a different effective rate that others, and thus
will drift out of sync. ( Eg, lets say one computer has a natural
offset of 200PPM and another  is -100PPM. When both are slewing at
500PPM, one is effectively slewing at 300 PPM and the other at 600,
which goes out by 50ms in about an hour. 
Ie, because of the slew rate limits in ntp, keeping them in sync by
slewing is also not guarenteed. 

More information about the questions mailing list