Configuring the Time Synchronization Protocol (TSP)

TSP guidelines

While the synchronization algorithm is quite general, the election algorithm, which requires a broadcast mechanism, puts constraints on the kind of network on which timed can run. One restriction is that you should run timed only on networks with broadcast capability, possibly augmented with point-to-point links. Another restriction is that the maximum number of hosts that can be directly controlled by one master time daemon is 1013.

If submasters are excluded, there is normally only one master time daemon running on a given LAN. During an election, only one of the slave time daemons becomes the new master. Not all hosts are suitable as masters, however. Because a master time daemon requires CPU resources proportional to the number of slaves it controls, you should consider running a master only on hosts with more powerful processors or lighter processing loads. Also, hosts with inaccurate clocks should not be used as masters. Note that this is a purely administrative decision. You are free to allow all of the hosts on your network to be a master.

At startup time, a time daemon running on a host connected to multiple networks may be instructed to recognize specific networks with the -n option or to ignore specific networks with the -i option. Note that both options cannot be specified together. In other words, you can recognize certain networks or ignore certain networks, but you cannot do both. Typically, you would instruct the time daemon to ignore all networks except those that are under local administrative control.

If you run timed on several different LANs connected over gateways, you should avoid the situation where two gateways are both connected to the same two networks, and where the time daemons on those gateways play opposite master/slave roles on those networks. For example, suppose hosts A and B are gateways that are both connected to networks X and Y. If timed is started on both A and B with the -M option, it is possible for the time daemon on gateway A to become a slave on network X and the master on network Y, while the time daemon on gateway B can become a slave on network Y and the master on network X. If this kind of loop exists, the master time daemons do not function properly to establish a single value for time on both of the networks. It also causes the submasters to use large amounts of system resources in the form of network bandwidth and CPU time. This kind of loop can also be generated with more than two gateways, in the case where several LANs are interconnected.

Next topic: TSP options
Previous topic: Electing a new TSP master

© 2003 Caldera International, Inc. All rights reserved.
SCO OpenServer Release 5.0.7 -- 11 February 2003