[ntp:questions] Re: ntpd -x

David L. Mills mills at udel.edu
Fri Jan 27 17:09:52 UTC 2006


At the very real risk of boring everybody on this list to tears, I have 
a burning agenda to expose this issue to a responsible community.

Your flight dispatcher machines are running just fine and one of them 
suddenly veers off course by one hour. Your application is airt traffic 
control. Your choices are:

1. Immediately shut down the timewarper and dispatch a repair crew.

2. Force the timewarper to slew, even though it will take a week to slew 
within one second, your sanity limit. During most of the week the warper 
clock will be ahead of the rest by more than the sanity limit. Of 
course, a rew airplanes might collide, but will crash in monotonic order.

3. Step the clock back, possibly confusing flight planning, but at least 
all planning is to the same clock and nobody crashes.

Comments from your database gurus, ALPA and PATCO would be highly prized.


Joel Shellman wrote:
> --- "David L. Mills" <mills at udel.edu> wrote:
>>The only thing the -x option does is change the step
>>threshold to 600 s, 
>>or ten minutes. I find it mighty curious that you
>>would consider a large 
>>discrepancy like that within acceptable bounds for a
>>any consistent 
>>distributed data system, but that's not my call.
> I plan to run ntpd -q -g upon system startup, so that
> discrepancy "should" never happen. However, the most
> important requirement is to have a sequential clock so
> that timestamps on audit logs are sequential. Also,
> this is in an isolated environment--probably won't be
> using public servers.
>>Note that the tinkers disable all steps for any
>>reason, including a step 
>>at startup. If you need that, you will need another
>>program or to start 
>>ntpd in ntpdate mode before launching the daemon.
> Right, which we're planning on doing anyway.
> You made me think though. It sounds like what we
> really want is:
> tinker panic 5 # or some appropriately small number
> tinker step 0
> After running ntpd -q -g on system startup, we should
> have the same clock. So long as the clocks aren't so
> incredibly off as to lose or gain 5 seconds, we should
> stay within 5 seconds and never clock step. And if we
> get 5 seconds off, ntpd dies, alarms go off and
> someone manually figures out why the clocks aren't
> able to stay within 5 seconds of each other.
> Thank you very much for your help.
> -joel
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> _______________________________________________
> questions mailing list
> questions at lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions

More information about the questions mailing list