--- "David L. Mills" <mills@xxxxxxxx> 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.
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
questions mailing list