[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