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

William Unruh unruh at invalid.ca
Thu Feb 12 18:44:29 UTC 2015


On 2015-02-12, Rob <nomail at example.com> wrote:
> William Unruh <unruh at invalid.ca> wrote:
>> On 2015-02-12, Rob <nomail at example.com> wrote:
>>> Brian Inglis <Brian.Inglis at SystematicSw.ab.ca> wrote:
>>>> On 2015-02-12 03:00, Rob wrote:
>>>>> catherine.wei1989 at gmail.com <catherine.wei1989 at gmail.com> wrote:
>>>>>> Yes,I just tested it and found that the synchronization of NTP is really slow.
>>>>>
>>>>> That is because ntpd is not designed to correct arbitrary errors that
>>>>> you have applied externally.  It is designed to lock to the correct time
>>>>> and stay locked to that (within a few milliseconds when you use the network,
>>>>> or within a few microseconds when you have a local reference).
>>>>>
>>>>> The typical "acceptance test" scenario of "let's set the clock one hour
>>>>> wrong while the system is running and see that ntpd corrects it" just is
>>>>> not going to work.  Drop that test, it should not be on the test list
>>>>> for ntpd.  When you need that test, use another product.
>>>>
>>>> The test should be:
>>>> set the clock one hour wrong;
>>>> start ntpd -g;
>>>> measure how long it takes to get within 128ms, 64ms, 32ms, 16ms, ... of UTC;
>>>
>>> Yes, that would work.  But that was obviously not how it was tested and
>>> I have seen this kind of posting here many times.  It is apparently a
>>> common (wrong) way of testing.
>>
>> She never said how she tested it, so making assumptions and then blaming
>> her on the basis of those assumptions is hardly fair. 
>
> She did.  It was written in the first post that the time on the system

OK, I did not remember that it was the same person. However, this comment
she made was not necessarily based on that same test. She might have
learned when she was disciplined by the group, and tried a different
test (eg set the clock wrong by 100ms and see how long it takes to
recover).

> clock was manually changed by one hour and then the offset was monitored.

Which should have waited for 900 sec, and then the clock was stepped. 
By the way, I do nt know whether ntpd suspends all clock discipline in
that 900 sec, or whether the discipline continues. Ie, in that 900 sec
does ntpd try to get rid of that offset by changing the drift rate or
does it hold any such drift changes in abayance while it waits to see if
this was just an anomaly?



More information about the questions mailing list