I'm not really sure about this, but I think you need a *high*
offset, like in the order of an hour, before ntpd refused to
adjust. I know it happely does 5 minutes.
> There are lots of high quality and cost hardware solutions. The
> solution in my first post was a very small kernel patch to add an
> 11 minute update log so hwclock etc could adjust the time. Any
> comments on my patch?
Note that hwclock does not adjust the clock if the error is
smaller than 1 second, or it already wrote to the RTC is the past
23 hours.
It would only help if your box was down for more then a day. In
that case it probably also drifted for more then a second.
I don't know how to set up ntpd to synch to the RTC clock, but I
doubt it would take the drift it has into account.
Also note that in case the kernel writes the time to the RTC
clock, hwclock can't calculate the drift it has properly because
it is calculated the time it writes to the RTC.
What you probably want to do is disable the kernel writing the
time to the RTC, and let hwclock do write the time to the RTC so
it can calculate the drift properly, and adjust for it during
startup.
Ntpd will also adjust the frequency of the system clock, and you
should get a reasonable accurate time.
Btw: Last time I looked at it (util-linux-2.11h), the calculation
of the driftfactor in hwclock was still pretty inaccurate. I
once did send patch for it, but it doesn't seem to be included.
There also is an adjtime.patch included you could use.
Kurt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/