[ntp:questions] Re: ntpdate functions successors
David L. Mills
mills at udel.edu
Tue Oct 5 19:36:45 UTC 2004
I explained why this is a bad idea in my previous messages. Setting
tinker step 0 is just about the most dangerous thing you can do. It
would in principle allow you to slew when the system time is 34 years
from now, which would take several years to amortize. Setting it to
something like 600 seconds would be reasonable, as long as you agree
that the permisable error between clocks on the network can be as high
as ten minutes and it will take probably a day to amortize.
What's even worse, at least on some systems (Solaris), the adjtime()
routine has been modified from the original Unix and the correction for
offsets that large would certainly be unstable. To further mess the
issue, the kernel can handle offsets only to 0.5 second. While the ntpd
daemon uses its own discipline above that and switches to the kernel
below that, the transition will very likely not be seamless.
The bottom line, as I have said so very many times so often in the
frequent past, is don't change the threshold above 0.5 second. If the
offset is greater than that, either take a step or stop all the
applications, take the step and restart the applications. This may sound
ridiculus, but this is exactly the advice given to IBM mainframe
customers (9037 Sysplex) when transitioning from DST to ST and avoiding
the one-hour step back.
Harlan Stenn wrote:
> I'm suggesting we leave the current behavior of "tinker step 0" alone,
> and consider using "tinker step -0" to mean "abort with a message saying
> what the time step would be".
> This would use all of the algorithms to select the best time from the
> set of servers.
> And I'm not saying this is a good idea - I think we can probably do better.
> Likewise, I'm wondering if we should let people configure ntp so that it
> will make forward steps, but only backwards slews. But this can be difficult
> and might be better served by support from the kernel, which should probably
> monotonically increase the time for each "what time is it" call until time
> "catches up" in this case. Again, not sure if this is a good idea, but
> there are cases that apparently need it. Apparently...
More information about the questions