[ntp:questions] Re: uclinux and ntpd
ndprasad at gmail.com
Tue May 23 01:35:29 UTC 2006
Thanx for the previous response. I did some more research on this by
trying to run the latest stable version ntpd. Removing the external
server and configuring one internal server (which is connected to the
gps source) or two internal servers.
I observe that some time, ntpd locks to the server first time and i
dont get any loss of synchronisation (nor any large time steps) and it
runs ok for long time with drift file showing 0.6ppm. But some other
time, it takes almost couple of hours to sync having large steps in
between. I verified that my adjtime works fine (i am using uClinux
with linux kernel version 2.4.32 which has tickadj as 5 (i.e 500/HZ).
My on board oscillator is TCXO with stability of +/- 0.8PPM. (So this
should be pretty stable).
I have given the log below of one of my systems when the shift
happens. Please let me know what other details are required.
Also, have the following questions.
Does it depend on the processor speed for the ntpd/jitter convergence
to work properly. I am running microblaze at 60mhz. I also have
software fpu instead of hardware. Is there any other factor that can
make this to take long time before it converges properly.
Please let me know any suggestion to improve this.
remote local st poll reach delay offset disp
*192.168.1.199 192.168.1.237 1 32 377 0.00049 0.026154 0.00232
Ouput of the ntp log:
>Jan 1 01:01:02 kernel: Clock: old time 1970/01/01 - 00:00:25
<5>Jan 1 01:01:02 kernel: Clock: new time 2005/01/01 - 01:01:00
<6>Jan 1 01:02:12 login: root login on `ttyp0' from `192.168.1.120'
<6>Jan 1 01:02:37 ntpd: synchronized to 192.168.1.199, stratum=1
<4>May 22 23:16:44 kernel: Set Time of Day 4472465b secs efc6e usecs
<5>May 22 23:16:44 kernel: Clock: old time 2005/01/01 - 01:02:37
<5>May 22 23:16:44 kernel: Clock: new time 2006/05/22 - 23:16:43
<5>May 22 23:16:44 ntpd: time reset +43798446.825870 s
<6>May 22 23:18:55 ntpd: synchronized to 192.168.1.199, stratum=1
<4>May 22 23:31:24 kernel: Set Time of Day 447249cc secs 70dd9 usecs
<5>May 22 23:31:24 ntpd: time reset +0.475924 s
<5>May 22 23:31:24 ntpd: kernel time sync enabled 0001
<6>May 22 23:33:32 ntpd: synchronized to 192.168.1.199, stratum=1
<4>May 23 00:14:05 kernel: Set Time of Day 447253cc secs f0e56 usecs
<5>May 23 00:14:05 ntpd: time reset -0.133558 s
<6>May 23 00:16:13 ntpd: synchronized to 192.168.1.199, stratum=1
<4>May 23 00:29:08 kernel: Set Time of Day 44725754 secs 4931f usecs
<5>May 23 00:29:08 ntpd: time reset +0.501980 s
<6>May 23 00:31:15 ntpd: synchronized to 192.168.1.199, stratum=1
<4>May 23 00:57:43 kernel: Set Time of Day 44725e07 secs 6f92f usecs
<5>May 23 00:57:43 ntpd: time reset -0.485352 s
<6>May 23 00:59:53 ntpd: synchronized to 192.168.1.199, stratum=1
<6>May 23 01:09:06 login: root login on `ttyp0' from `192.168.1.116'
"/var/log/messages" line 86 of 86 --100%--
# cat /var/lib/ntp/drift
On 5/18/06, David Woolley <david at djwhome.demon.co.uk> wrote:
> 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.
> questions mailing list
> questions at lists.ntp.isc.org
More information about the questions