scope:

Scope and Applicability

The methods specified in this EPI are designed to synchronize the internal clocks of hosts within the system together using fairly infrequent exchanges (minutes or even hours apart). Between exchanges, the internal clocks free run. These methods will therefore not work well if an internal clock's reference changes by significant amounts in an unpredictable way between exchanges. In practical terms, this means that a clock running from a quartz crystal will typically not have a significant effect on overall accuracy but clocks based on RC oscillators or even on ceramic resonators may not be acceptable - depending on the precise algorithms applied.

The SNTP protocol does not use the advanced averaging and compensation methods of full NTP and is therefore more susceptible to network latency effects and routing variations. Where all hosts are on a simple Ethernet network without excessive loading, accuracy will be good enough for nearly all entertainment synchronization requirements, however, where hosts are separated by many routers and complex network infrastructure with unknown traffic (e.g. the Internet), accuracy may be inadequate. More discussion of accuracy and methods for mitigation are given below.

It is strongly recommended that SNTP be used only at the extremities of the synchronization subnet ... and in configurations where no NTP or SNTP client is dependent on another SNTP client for synchronization.

-SNTP Version 4

The use of NTP and SNTP for synchronization is not suited to applications where very rapid synchronization to a reference which might change rapidly, pause, skip or move backwards such as for example, a video source. In these circumstances synchronization using a timecode method such as SMPTE LTC or MIDI Time Code is more appropriate.

The techniques used here all express time as calendar time or "time of day". The actual values used relate to the epoch that began at midnight (00:00) on January 1st 1900.