I have a set of Linux servers which are not known to each other a priori and 
the members of the set may come or go without notice. I need to main tight 
inter-server time synchronization: at least better than 5ms and preferably 
better than 1ms.

The set of server may or may not be connected to the wider Internet. Such a 
connection is likely but may not be reliable. Thus I cannot rely on it but wish 
to take advantage of its presence when possible to use external NTP sources for 
synchronization.

The servers in question use relatively low-power (ARM) CPUs. When synchronized 
to external NTP sources the servers maintain good synchronization. The 
following is considering the options when not connected, using the "tos orphan" 
option.

I have observed that, when idle, broadcast mode (actually multicast) mutually 
between the set of servers maintains good synchronization. However, when busy 
(especially with the network) offsets easily expand to > 50ms and I actually 
think that false synchronization is occurring. My understanding is that NTP 
broadcast mode uses an exchange of multiple packets (a bit like iburst mode) 
but I'm not seeing sufficiently reliable synchronization. On 
comp.protocols.time.ntp I saw a post that suggested increasing the broadcast 
frequency (to 4s) results in substantially better tracking but I have not tried 
that.

So my second idea is to use manycastclient mode with ttl set to 2 (I'm only 
interested in the local network(s)). Again, all servers configured mutually as 
both client and server. One problem is that it does not seem possible to 
configure iburst with this and so initial sync is rather slow. Another possible 
concern is that disjoint subsets of the servers could develop, given the way 
the manycastclient mode appears to operate. I'm wondering if I should use "tos 
cohort 1" with this configuration.

Any suggestions or observations welcome.

Alan

_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
  • [ntp:questions... consult . awy
    • Re: [ntp:... E-Mail Sent to this address will be added to the BlackLists

Reply via email to