[ntp:questions] NTP offset doesn't change.

William Unruh unruh at invalid.ca
Thu Feb 12 17:00:39 UTC 2015


On 2015-02-12, catherine.wei1989 at gmail.com <catherine.wei1989 at gmail.com> wrote:
> On Wednesday, February 11, 2015 at 12:55:02 AM UTC+8, Jochen Bern wrote:
>> On 02/10/2015 06:15 AM, catherine.wei1989 at gmail.com wrote:
>> > However, when I wait for several minutes, the time can be adjusted to
>> > the right time. I couldn't see the gradual changes of offset. Is that
>> > normal?
>> 
>> Assuming that you're using a minimalistic configuration: Yes.
>> 
>> ntpd would take almost three months to *gradually* eliminate (slew) one
>> hour of offset, so as soon as the
>> offset-from-hell-that-struck-us-out-of-the-blue-sky was confirmed, it
>> gave up all hope for the universe and "just set the clock" hard (step).
>> 
>> Regards,
>> 								J. Bern
>> -- 
>> *NEU* - NEC IT-Infrastruktur-Produkte im <http://www.linworks-shop.de/>:
>> Server--Storage--Virtualisierung--Management SW--Passion for Performance
>> Jochen Bern, Systemingenieur --- LINworks GmbH <http://www.LINworks.de/>
>> Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
>> PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
>> Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
>> Unternehmenssitz Weiterstadt, Gesch?ftsf?hrer Metin Dogan, Oliver Michel
>
>
>
> Yes,I just tested it and found that the synchronization of NTP is really slow.

There are two parts to this. The first is the large offset problem,
where delta t is many seconds. Here the 500PPM problem sets in and it
would take forever to fix that offset, so ntpd simply steps the clock if
the offset is greater than 128us, and quits if greater than 1000 sec
(unless you use the -g in which case it fixes that large an offset
once).
The other is if you have an offset of say 50ms, The ntpd takes a long
time because of design decisions. a) ntpd throws away about 7 out of 8
polls in order to "fix" the problem of wildly varying round trip times
even if there are no such wildly varying offset times. That makes the
effective poll interval 8 times longer than the actual poll interval.
And then ntpd only slowly changes to the drift rate to fix that offset
in order to keep the running of ntpd stable. The simply feedback loop
used by ntpd could go unstable if it changed the drift rate too quickly,
because the decision was to use an very simply  feedback mechanism to
run ntpd. (Probably on the KISS principle, and because it is easily
analysed to determine stability).
This means that if you are using say a PPS source, which gives
microsecond long term offset, it can take many hours to get there, even
if you or I looking at the offsets could see that it is off by ms after
the first few poll intervals. 
The decision to have stability and simplicity over speed was made a long
time ago by Mills.  It was not a bad decision, especially in the early
days when round trip times did fluctuate wildly sometimes, and where ms
resolution was doing well. Now that usec and nsec resolution is
possible, the design decisions are a bit more problematic.

>



More information about the questions mailing list