Tom Smith wrote: > [EMAIL PROTECTED] wrote: >> Hi, I've set up a ntpd on my linux box and at first it worked fine and >> got a stratum of 2 after a while. Then, after a couple of minutes, it >> got a stratum of 16 again. Now it hops back and forth and doesn't seem >> to be very stable at all. >> I sat and watched the output from peers in ntpq for a while, and first >> everything is fine but after a while all the remote servers get *+- etc >> in front of their names, I've tried to read what these mean but I'm >> don't really understand. >> >> Here's the output from ntpq peers: >> ntpq> peers >> remote refid st t when poll reach delay offset >> jitter >> ============================================================================== >> nissan.ifm.liu. .GPS. 1 u 16 64 17 27.721 -479.06 >> 115.831 >> timmy.lysator.l .GPS. 1 u 28 64 17 28.089 -380.49 >> 72.967 >> timehost.lysato .GPS. 1 u 40 64 17 28.833 -462.36 >> 111.578 >> Time1.Stupi.SE .PPS. 1 u 23 64 17 24.651 -313.99 >> 115.770 >> ntp1.sth.netnod .PPS. 1 u 28 64 17 26.199 -475.23 >> 119.470 >> ntp2.gbg.netnod .PPS. 1 u 51 64 17 32.007 -455.40 >> 123.874 > > . > > . > > . >> ntpq> peers >> remote refid st t when poll reach delay offset >> jitter >> ============================================================================== >> nissan.ifm.liu. .GPS. 1 u 112 64 36 27.721 -479.06 >> 115.831 >> *timmy.lysator.l .GPS. 1 u 58 64 37 28.089 -380.49 >> 118.008 >> +timehost.lysato .GPS. 1 u 8 64 77 27.253 -522.91 >> 141.296 >> -Time1.Stupi.SE .PPS. 1 u 53 64 37 24.651 -313.99 >> 169.327 >> +ntp1.sth.netnod .PPS. 1 u 58 64 37 26.199 -475.23 >> 116.326 >> +ntp2.gbg.netnod .PPS. 1 u 15 64 77 31.388 -633.99 >> 250.372 >> >> Why might does this happen? >> >> ntptrace shows this: >> localhost: stratum 16, offset 0.000000, synch distance 0.010290 >> > > You are starting with an offset of almost 1/2 second from your > sources. After 5 polls of the sources, your client selects a set > of servers to use as a reference. Those are the "*" and "+" > characters that appear in the first column. The "-" character > indicates a source that was rejected for one reason or another. > The source with an "*" is the "synchronization source". > > After a period of time during which the consensus offset is > deemed to be stable, the client will reset its clock to > try to bring the offset to 0. When this happens, the client > stratum goes back to 16 (unsynchronized) until it synchronizes > again. The same synchronization sequence then repeats > indefinitely. > > You should expect this to happen repeatedly for several > hours or even for a day or 2 until your client computes its > characteristic drift rate and is able to cruise along > between polls at approximately the same rate as the > clocks you are using as sources. > > You can accelerate the process as follows: > > 1) Stop ntpd > 2) Add "iburst" to the end of each of your server lines in ntp.conf > 3) make sure you have a (valid) driftfile declaration in ntp.conf > 4) Delete any existing ntp.drift file > 5) Use "ntpdate -b [server]" to set your clock to the > correct time. This should be part of your boot or ntpd start sequence. > It is configured differently for different Linux distributions. > Red Hat, for example, uses the file /etc/ntp/step-tickers to list > the servers that ntpdate should use on initial startup.
Skip this step. Use ntpd -g instead when starting ntpd. This will set the clock even if it's way off. > 6) Start ntpd. > 7) Let ntpd run for at least a day without disturbing it > > -Tom > > _______________________________________________ > 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
