Miguel Cruz writes:

The most reasonable way to ensure they are relatively accurate is to
ensure they are absolutely accurate.

Not necessarily. It may be cheaper to provide very stable time
references for the network for relative measurement rather than try to
derive those measures from an ultra-accurate time-of-day source. This
is especially true since the accuracy required might be microseconds
or better, and this is expensive to derive from the time of day.

For example, most time of day sources provide extremely high long-term
accuracy at low cost, but they provide poor short-term accuracy unless
a great deal of effort and money is expended. A radio source will
keep your network locked to the correct time of day with long-term
accuracy equal to that of the best atomic clocks, but the short-term
accuracy may be off by hundreds of milliseconds per day unless you
spend a great deal on either continuous synchronization or a local
reference that is extremely accurate when free-running. In the latter
case, you might as well skip the time-of-day reference.

In summary, for timing of protocols, you don't necessarily need
accurate time of day. However, for things like time stamps, and
synchronization of events with precision over long periods or
distances, time of day can be very useful.

One application that illustrates this is live television. In the days
when live television was common and nationally broadcast, sometimes
studios on one coast would pick up where another left off. If they
didn't have their clocks synchronized to within a fraction of a
second, either there would be a period of dead air or a period of
confusion whenever one location handed off to another.

Accurate time of day is important for things like electronic money
transfers and stock operations, too.

--
Transpose mxsmanic and gmail to reach me by e-mail.