[ntp:questions] testing slew only mode (-x), not slewing correctly (linux sles10, ntpd v 4.1.1)

David Mills mills at udel.edu
Fri Oct 23 16:28:15 UTC 2009


Brian,

There is a total disconnect here. In the NTP distribution that leaves 
here the only occasion when the reported message is reported is in 
ntpdate mode shortly before the program exits. The message is not 
reported in any other case, so never can appear more than once.  There 
is only one slew mode enabled either by command line option or by tinker 
command. The only thing it does is adjust or eliminate the step 
threshold. There is no question of stability, as the discipline loop is 
unchanged.

However, as I have advised many time in the past, Solaris and Linux, 
among others, have introduced a kernel modification that introduces an 
additional pole in the transient response. This will most certainly 
result in unstable behavior when the residual offset is in the order of 
a second or more. This is not a bug in ntpd, it is a consequence of 
physics and feedback loop dynamics. If slew mode is required and large 
residual offsets are expected, do not run the daemon continuously; run 
ntpd in ntpdate mode from a cron job. A much better solution is to 
remove the kernel modification and restor the original Unix functionalilty.

Dave

Brian Utterback wrote:

>JohnLund wrote:
>  
>
>>If slewing were working I would think that the "time slew" shown in
>>the log file would be continuously decreasing.  Instead it seems to be
>>unpredictably increasing (and decreasing at times), as if this mode
>>were unstable.  I looked in the systems /var/log/messages file to see
>>    
>>
>
>And indeed, slewalways mode is unstable. That is why it was changed to 
>a "slew mostly" mode in later versions.
>
>  
>
>>if there are any system messages about the clock, and only see the
>>changes from running ntpdate at startup to set the system time from
>>the configured NTP server (before the time jump).
>>
>>Also it looks like the drift/frequency is set to a large negative
>>number by ntpd, when it would seem logical with a large positive time
>>jump that the frequency should be changed to a large positive number
>>in order to slew toward correct time.
>>    
>>
>
>Think about this from the daemons point of view. I bet you used some 
>external tool like the date command to set the clock while NTP was 
>running, didn't you. From the point of view of NTP, the clock is now 
>ahead by one minute, and it got that way in some small interval of 
>time since the last time it set the clock. Well, if your clock turns 
>up one minute ahead after 5 minutes then you are going to think that 
>your clock runs way too fast. So, now you slow it down by a lot to 
>compensate.
>
>Remember also that slew mode adjusts the clock by 500ppm. That means 
>that it will take 33 hours to correct the 1 minute offset. It will 
>probably be nearly as long to iron out the perturbation of the clock 
>frequency as well, so the clock will not be running at the right speed 
>for much of that time, so it might even be much longer before the 
>offset disappears and stays gone.
>
>Remember, when NTP is running, nothing, nothing, nothing else should 
>be adjusting the clock.
>
>Brian Utterback
>
>_______________________________________________
>questions mailing list
>questions at lists.ntp.org
>https://lists.ntp.org/mailman/listinfo/questions
>  
>




More information about the questions mailing list