On 2013-07-08, [email protected] <[email protected]> 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 > 127.127.1.0 as a fallback - "if no NTP server available, give devices at > least your wrong timestamp and get all synched with it".
Read up on "orphan mode". > 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. I believe you can "tinker" that .128 sec time for jumps. Or run chrony which will let you drift for longer times, HOwever the drift rates of the various clocks during that fixup period could well get you outside that window of 50ms. if the offset from "true time" is long enough. Note that part of your problems could be mitigated by doing more rapid plling. Ie, if max poll is 4 (16 sec) then that would be the max time they would be out of sync. > Thanks in advance for your advises! > Igor. _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
