quick status check

[Hal Murray]

verm at darkbeer.org said:
> The issue with doing this is it's difficult to get repeatable builds on the
> timestamps.

What does that mean?  How close to you need the time to be?

Running our code should work as well as running ntp classic.  If not, we 
should track it down.


> You're right at the start setting the time to a wrong amount and seeing if
> ntpd  keeps it in sync will work.  I'm looking for offset testing where we
> do it for <  10sec, 1 day, 1 week.  This way we know what's going on every 7
> days max. 

I can't figure out what you have in mind.

ntpd has two modes for adjusting the time.  For small adjustments, the kernel 
slews the time by adjusting the ticks per second.  The clock just ticks a 
little faster or slower.  I think most kernels use 500 PPM, but I wouldn't be 
surprised by something strange.  For large adjustments (over 128 ms), ntpd 
just smashes the time (aka step).  For huge adjustments, ntpd panics and 
waits for a human to fix things.  I think the panic threshold defaults to 
1000 seconds.

There is a command line flag to disable jumps.  Many data bases don't want 
the clock to step backwards.    It will take a long time to slew 1000 seconds.

There is another flag to allow one huge adjustment at startup time.


It would be nice if we could test that tangle.  I don't see how to automate 
it, but it's probably worth doing by hand for each release.  (Stepping was 
broken for a while last week.)


Run time testing is testing the kernel and network as well as ntpd.


-- 
These are my opinions.  I hate spam.