[ntp:questions] Broadcast (multicast) or manycastclient mode for sometimes isolated network of servers?

consult.awy at gmail.com consult.awy at gmail.com
Thu Nov 15 12:28:03 UTC 2012

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.


More information about the questions mailing list