In this implementation of TSP, the timed(ADMN) time daemon runs on each host on your network. These time daemons communicate with each other using a master-slave scheme in which one of the daemons is the master and all of the remaining daemons are slaves.
Each time daemon has two functions:
The remainder of this chapter covers
how the time daemon works,
guidelines for using TSP,
timed
options,
and
basic TSP administration.
How the time daemon works
A master time daemon measures the time
differences between the clock of the host on which it
is running and those of all the other hosts on the network.
The master computes the network time as the average of the
times provided by slaves on hosts whose clocks are not faulty.
In this scheme, a host's clock is considered faulty if its time differs
from that of the majority of the clocks on the network
by more than a specified amount. The master time daemon then
sends to each slave time daemon the
correction that should be applied to its host's clock.
This process is repeated periodically.
Because the correction is expressed as a time difference rather than an
absolute time, transmission delays do not interfere with
the accuracy of the synchronization.
Whenever a host comes up on the network,
it starts a slave time daemon that
asks the master for the correct time and resets the host's clock
before any user activity can begin.
The time daemons are thus able to maintain a single network time in spite of
the drift of clocks away from each other. The present implementation
of timed is capable of keeping processor clocks
synchronized to within 20 milliseconds,
but some clocks, because of their design, cannot be adjusted to within
an interval smaller than 1 second.
Electing a new TSP master
To ensure that the time synchronization service provided is
continuous and reliable
in the face of unusual events, an election algorithm is
available to elect a new master. Unusual events include:
Running timed on gateways that connect distinct Local Area Networks (LANs) requires particular care, because the time daemon may act as a ``submaster''. A submaster is a time daemon that functions as a slave on one of the networks the gateway is connected to and as a master on one or more of the remaining networks. Submasters are necessary to overcome the restriction of current transmission protocols' preventing broadcasts from being transmitted over multiple physical networks.
A submaster classifies the networks that the gateway is connected to into the following three types:
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.
TSP options
The options for the timed command are:
------------------------------------------------------------------ Manual page Purpose ------------------------------------------------------------------ rdate(ADMN) notify time server that date has changed timed(ADMN) time server daemon timedc(ADMN) timed control programTo get more information about TSP, see the following Requests for Comments (RFC).
------------------------------------------------------------------ RFC Title ------------------------------------------------------------------ 868 Time Protocol