[ntp:questions] Re: ntpdate functions successors

[David L. Mills]

Harlan,

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.

Dave

Harlan Stenn wrote:
> Dave,
> 
> 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...
> 
> H