[ntp:questions] Re: uclinux and ntpd

David Woolley david at djwhome.demon.co.uk
Thu May 18 07:25:50 UTC 2006


In article <3351bfbe0605161922n469961c7kd17ada64f6fea2c5 at mail.gmail.com>,
ndprasad at gmail.com (DeviPrasad Natesan) wrote:

> Has anybody running ntpd successfully without stratum drift in the

A change from stratum 2 to 16 isn't a "stratum drift" it's a loss of
synchronisation, and the relatively large time step is probably a clue,
but you haven't provided enough of the log to really establish a trend.
(Steps in the same direction are indicative of lost clock interrupts,
something other than ntpd disciplining the clock or a static frequency
error outside the permitted range.)

> *192.168.1.199   192.168.1.104    1   64   37 0.00174 -0.596261 0.43750

The server here has a stratum zero, not a stratum 1 source, but if it
really has a stratum zero source, the refid should be the special code
for the reference clock driver!

> =ems02.your-free 192.168.1.104    3   64   37 0.00000  0.000000 0.43750

This second line is virtually impossible!  The only time you will get
zero delay and zero offset legitimately is for the local clock pseudo
driver, which you shouldn't have configured, and ought to be specifically
identified above.

It is possible for two servers at different stratums to have the 
same refid, because their upstream server may have changed stratum between
the polls from the two different immediate upstream servers, but stratum
zero servers (reference clocks) cannot change stratum.  However, I've
already pointed out, that stratum zero sources are normally identified
by special codes.

In any case (although we don't have root delay and dispersion to
be sure)  your two time sources seem to have irreconcilably different
concepts of the time.

I would say that the clocks are initially assumed compatible because the
jitter calculation hasn't converged, but once jitter converges it becomes
clear that they are incompatible.  Two servers is about the worst possible
number for resolving this sort of conflict.

At the moment, the only reason I can think of for the zero offsets is
that the machine has a very poor time reading precision and simply cannot
tell the difference between zero and the true values, and that ems02 is
the same type of machine.




More information about the questions mailing list