[ntp:questions] Re: NTP stepping issue

[David L. Mills]

Robert,

I have confronted Linux many, many times with broken this and that and 
concluded I will not attempt to examine, fix or judge anything Linux. 
You are on your own.

Dave

Robert Rati wrote:

> 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
>>