[ntp:questions] Re: NTP Loses sync over time.

David Woolley david at djwhome.demon.co.uk
Sat May 13 13:46:58 UTC 2006

In article <1CFDE047B92CFA46AF1A9033EF0C615C015D0527 at mail01dn.adic.com>,
brian.szmyd at adic.com (Brian Szmyd) wrote:

> We have a customer using our product running SNTP v4 and they have

SNTP is not NTP and one can expect SNTP implementations to drift by 
the full clock frequency error between polls.

> having trouble keeping the machine in sync with their v3 NTP server.

Obvious question:  have they actually told the client to use the down
version (obsolete) version 3 protocol?

> They are seeing a drift of about a minute a day...and I really have no

A minute a day exceeds the capture range of the full version 4 NTP 
implementation.  Whilst SNTP might not care about this, it indicates the
client and/or server are running on broken hardware or the one that is
slow is losing clock interrupts.  If the server is using a broken source
of time (as it looks like it is) the drift error could be split between
client and server.

You should aim to fix the hardware so that the error is no more than
about 20 seconds a day, although 3 seconds would be more realistic for
good hardware.  (20 seconds is something like the worst from cheap,
but working, hardware.  A full, version 4, ntpd can cope with a machine
with an error of about 43 seconds, a day, but really needs some safety
margin, and this is worse than I have seen for unbroken hardware.)

> If I look at the Frames under Ethereal I see:

> ....
> Clock Dispersion:	10.2222 sec

This is incomplete and doesn't use standard terminology.  I assume that this
is Root Dispersion, in which case the server is indicating that its time is
so broken than no standard implementation will touch it.  Root dispersion is
an estimate of the maximum accumulated error since a real reference clock
was read.  I believe that the protocol shuts down when it reaches one second.

If you had all the parameters, you might find other fault indicators.

> Reference Clock ID: uncalibrated local clock

This almost certainly indicates an unsupported configuration.  NTP should 
always have ultimate recourse to a reference clock that is locked to true

> Reference Clock Update Time: May  4, 2006 08:52.53.0510 UTC

This indicates the last time at which the packet sender updated its clock
from an upstream source.  This is weird, as one of the things about using
the local clock reference is that it pretends that the time was set 
accurately every 64 seconds, even though it can be completely bogus.  I 
wonder if this is not really an NTP server at all, but one of the original,
broken, Microsoft SNTP servers.  One thing I believe that can do is to
reflect back the client's root delay and dispersion.

> Originate Time Stamp: May  4, 2006 13:50:18.8941 UTC

This is the time at which the other machine last sent to the current
sending machine, using its idea of the time.

> Receive Time Stamp: May  4, 2006 13:50:18.3950 UTC

This is the time at which the current sending machine received the packet
to which this is a response.

> Transmit Time Stamp: May  4, 2006 13:50:18.3950

This is the time that it sent the response.

> Clock Dispersion: What is this?

Probably Root Dispersion.  See RFC 1305.

> Ref. Clock ID: "
> Ref. Clock Update Time: I assume this is the time that this server was
> last updated?
> Originate Time Stamp: Meaning?
> Receive Time Stamp: "
> Transmit Time Stamp: Time the packet was transmitted?

These are all basic NTP concepts described in RFC 1305.

> Do these fields have different meanings in the context of Client to
> Server and vice-versa?

The protocol doesn't clearly distinguish between client and server, although
an SNTP client can't, I think, use one of the symmetric modes.  However,
request Transmit becomes response Originate.

>                        Which fields should be closing the gap and what

If you are using SNTP with a simple clock discipline algorithm, the values
should always reflect the drift of the client since the last poll, so
should not be closing when properly synchronised.

> does it mean to have them actually drifting apart? The Polling Interval
> is 6 seconds if that is of any value.

That is extremely fast!

500ms in 6 seconds is so far over the maximum plausible drift rate that
it is reasonable to assume the server is being ignored.  If the figure
quoted, is Root Dispersion, that should be sufficient for it to be
ignored, but I suspect it may well be showing an alarm state and stratum
16 as well (if it is showing stratum 2, that is almost a guarantee that
it is not NTP, but rather W32Time's broken SNTP).

Note, if you used a real NTP client, it wouldn't poll more often than every
64 seconds, by default, and would typically poll every 1024.

More information about the questions mailing list