[ntp:questions] time delta between clients

Richard B. Gilbert rgilbert88 at comcast.net
Wed Dec 12 19:57:39 UTC 2007


Rick Jones wrote:
> David Woolley <david at ex.djwhome.demon.co.uk.invalid> wrote:
> 
>>In article <fjn9i7$4v8$2 at usenet01.boi.hp.com>,
>>Rick Jones <rick.jones2 at hp.com> wrote:
> 
> 
>>>taps with clue bats, is if I can take the difference in offset
>>>between each client and the time server and ass-u-me that is the
>>>difference in time between the two clients.  Or do I have to do
>>>something ntp-like
>>
> 
>>No.  If NTP is working properly, it is actually an indication of the
>>order of magnitude of the error you can expect in measuring the
>>combination of network and system timing.  The actual system timing
>>variation should be considerably less than this, but there may be a
>>systematic bias, even if offset is consistently almost zero.
> 
> 
> <Demonstrate ignoranve mode on> Systematic bias? </>
> 
>>The NTP clock discipline will strive to zero the offset, but cannot
>>correct for round trip asymmetry.  Any individual offset measurement
>>will contain a measurement error.  That measurement error will be of
>>the same magnitude as the measurement error you will get with your
>>application.  If you are interested in one way latency, you are
>>interested in asymmetry!
> 
> 
> I think that in 99 cases out of 10 this would be run on a LAN where I
> have a decent expectation of symmetry :) Or at least the first places
> _I_ would be running it would be on a LAN :) Netperf can and does get
> run over WAN's where any hope of symmetry is out the window, but I'm
> willing to caveat that in the documentation.
> 
> 
>>To the extent that the above is not true, either you are making use
>>of information not available to NTP (like recent temperature
>>excursions), or the NTP algorithms need fixing.
> 
> 
>>You need to use local, probably GPS, reference clocks, with pulse
>>per second feeds, to remove network asymmetry.
> 
> 
> Is that need, Need, or NEED?  Is there is a way to be "good enough"
> without having the dependence upon anything more than the two
> endpoints being sync'ed to the same time source? (Other than the same
> GPS constellation received independently by each via their own PPS
> pucks that is)
> 

Define "good enough"!  How close must synchronization be between 
machines on your LAN?  How accurate must the time be?

Note that having a stable source of time, such as a GPS receiver, can 
strongly affect the tightness of synchronization.  It's analogous to the 
difference in difficulty of hitting a stationary target versus a moving 
target.

I've done it with and without GPS.  GPS is better as long as you can 
site an antenna with a good view of the sky.  With GPS I can keep the 
herd within one millisecond.





More information about the questions mailing list