[ntp:questions] Re: NTP stepping issue

Robert Rati Robert.Rati at motorola.com
Wed Oct 20 13:05:56 UTC 2004


Sorry, I meant to mention the system I was running on about three posts 
ago. :)  I'm running on an old PPC Linux distribution that has been 
slightly updated in order to run the 2.4.20 kernel.  It's a painfully 
old distribution, but I can't move forward unfortunately.

I'm not so much concerned with how long it takes to synchronize, just so 
long as it does synchronize and stay synchronized.  Does the problem you 
describe below exist with the Linux 2.4.20 kernel?  Is there a way to 
tell the NTP daemon not to slew faster than 500 PPM no matter how far 
off the time is (and would that solve the over-shooting problem)?

I've included my ntp.conf file incase I've accidentally configured 
something that is helping cause this problem (or haven't configured 
something that would help prevent it).

restrict default ignore
restrict 127.0.0.0 mask 255.0.0.0 notrust
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10
tinker panic 0
restrict <server1> noquery
server <server1> maxpoll 12 version 3 prefer
restrict <server2> noquery
server <server2> maxpoll 12 version 3

It shouldn't matter that I've had to disable the driftfile, right?.

Rob

David L. Mills wrote:
> Robert,
> 
> You are not going to like this answer. I mentioned awhile back that 
> Solaris, at least, had fiddled with the adjtime() syscall to speed up 
> convergence for large adjustments, effectively adding an additional pole 
> to the carefully crafted impulse response built into ntpd. The result 
> expected is serious overshoot at large offsets, just as you describe. 
> There is no help for it other than to use the kernel modifications, but 
> the existing modifications were designed only for offsets less than 0.5 
> second.
> 
> I don't know what system you are using, but if it slews faster than 500 
> PPM, expect trouble.
> 
> Dave
> 
> Robert Rati wrote:
> 
>> Let me test for understanding here, as I've gotten a number of replies 
>> to my question.  While it is possible to configure the NTP client 
>> daemon to step regardless of the time difference (as I have done), it 
>> is not recommended to do so.  In my testing, I saw the client daemon 
>> slew to the correct time but then it continued slewing past the 
>> correct time. Is this a bug?  Once it slews to the correct time 
>> provided by the servers, the client should remain synchronized, right?
>>
>> Is there another way to solve the problem I laid out? (Once daemon is 
>> running, always step no matter what the time difference and eventually 
>> stay synchronized with the time servers)
>>
>> Rob
>>
>> David Woolley wrote:
>>
>>> In article <416CA8D9.2050803 at udel.edu>, David L. Mills 
>>> <mills at udel.edu> wrote:
>>>
>>>
>>>> No, I did intend a small nonzero value. If I understood the question 
>>>
>>>
>>>
>>>
>>> This reply doesn't make sense.  It might have made a little more sense
>>> if it weren't top posted, so I could work out which statement you 
>>> were referring to, but even if we assume it is the tinker command 
>>> parameters, the original article:
>>>
>>> 1) had no mention of any value for tinker step;
>>>
>>> 2) only mentioned tinkering a parameter to exactly zero;
>>>
>>> 3) didn't mention that you had made any prior suggestion.
>>>
>>> Setting step to a very small value would effectively force ntpd into
>>> permanent frequency mode, stepping the time and frequency every  20 
>>> or so minutes.
>>>
>>>
>>>> correctly, the wish was to step the clock no matter what the offset. 
>>>> I wouldn't recommend that, but it can be done.
>>>
>>>
>>>
>>>
>>> The original article said that stepping was absolutely unacceptable 
>>> after
>>> any initialisation step.
>>>
>>> David Woolley wrote:
>>>
>>>
>>>> In article <mailman.23.1097522252.72027.questions at lists.ntp.isc.org>,
>>>> Robert Rati <Robert.Rati at motorola.com> wrote:
>>>>
>>>>
>>>>
>>>>> tinker panic 0
>>>>
>>>>
>>>>
>>>>
>>>> I assume that this is a typo and you meant "tinker step 0".
>>>
>>>
>>>
>>> _______________________________________________
>>> questions mailing list
>>> questions at lists.ntp.isc.org
>>> https://lists.ntp.isc.org/mailman/listinfo/questions
>>>
> 
> _______________________________________________
> questions mailing list
> questions at lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions
> 



More information about the questions mailing list