NTPD unable to adjust local clock
dillon at apollo.backplane.com
Wed Apr 6 11:10:42 PDT 2005
:On Wed, Apr 06, 2005 at 10:36:23AM -0700, Matthew Dillon wrote:
:> It's a little more complicated then that, but it's doable. Actually
:> it's a lot more complicated then that.
:No risk, no fun :)
:> First, we have to do away with ntpd's code that tries to take the
:> average from multiple time sources. What a disaster that is! At
:> the very *best* we can have a heuristic based on the offsets from
:> each source to try to correct the offsets, but otherwise we have to
:> choose the best time source (lowest standard deviation at the lowest
:> stratum) and stick with it. None of this averaging between sources
:> business. Each time source has to be independantly tracked and we
:> pick the best one, period.
:It's not that simple. You have to ensure that even a low-stratum source
:(perhaps with the exception of stratum 0 aka local time source) isn't
:horrible wrong to prevent an upstream time server from changing your
:local time, just because it is the lowest source reachable. That's asking
:for a DOS exploit.
Mmm... averaging time sources is not going to make the problem work
out any better. All averaging time sources does is add confusion.
Believe me, you do NOT want to average time sources. You can put in
sanity checks, but don't average time sources.
In anycase, I'll be happy to test whatever you come up with. We need
to get this done in the next few months, though, we can't let it hang
for another year.
:> The standard
:> system adjtime() call should only be used in an emergency, such as if
:> the time is say greater then 10 minutes off, or not used at all.
:Once we use ntp_adjtime [or a similiar syscall, I have to check first],
:there isn't any reason to use adjtime anymore. To handle large offsets,
:you still pretty much need settimeofday.
Correct, but beware improperly calling settimeofday() simply due to
a clock's frequency error being large. e.g. after doing an initial
settimeofday() a 5 minute sampling delay could cause the error to exceed
whatever threshold had been set and ntpd would wind up just doing steps
and *never* being able to fix the frequency. Or something of that
nature. At the same time, you can't correct a frequency error, even
a horrendously bad one, with just a few samples.. it still takes a
a good 8 samples and a standard-deviation calculation to know that
you've got a real, correctable frequency drift.
<dillon at xxxxxxxxxxxxx>
More information about the Users