Hi david, 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[156]: root login on `ttyp0' from `192.168.1.120' <6>Jan 1 01:02:37 ntpd[145]: 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[145]: time reset +43798446.825870 s <6>May 22 23:18:55 ntpd[145]: 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[145]: time reset +0.475924 s <5>May 22 23:31:24 ntpd[145]: kernel time sync enabled 0001 <6>May 22 23:33:32 ntpd[145]: 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[145]: time reset -0.133558 s <6>May 23 00:16:13 ntpd[145]: 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[145]: time reset +0.501980 s <6>May 23 00:31:15 ntpd[145]: 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[145]: time reset -0.485352 s <6>May 23 00:59:53 ntpd[145]: synchronized to 192.168.1.199, stratum=1 <6>May 23 01:09:06 login[161]: root login on `ttyp0' from `192.168.1.116' "/var/log/messages" line 86 of 86 --100%-- # cat /var/lib/ntp/drift -82.338 ========================================= On 5/18/06, David Woolley <[EMAIL PROTECTED]> wrote:
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (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 [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
_______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
