On Wed, 10 Jul 2002, Jonathan Stone wrote:

> David,
>
> Here is a post-facto but pretty pragmatic answer:
>
> If you really care about clock accuracy, you are running NTPD.

Jonathan, I think your level of "really" care is more like REALLY care for
a number of folks. While I think it's perfectly fine that you care about
ntp that much (and bash on things to make it work, like the PPS stuff we
did years ago), I think we should leave space for less enthusiastic points
of view. :-)

> If you are running NTPD, then the kernel's idea of the time *will* be
> better than a PC CMOS clock ("dallas" RTC or moral equivalent, or the
> Intersil(?) used in early Sparcs). So the kernel should write its
> NTP-disciplined time back to the battery-backed up clock on shutdown.
>
> Conversely, if you're not running NTP, and the kernel drifts, then
> there is little damage from writing the kernel time back to the
> battery-backed-up RTC chip -- since, as you're not running NTP, you
> clearly aren't too fussed about the accuracy of your clock.

That's a gross oversimplification. There's, "not caring", and then there's
caring but not REALLY caring about the clock; there are shades of gray in
there. :-) For one, to run ntpd requires network connectivity, which not
everyone has continually.

Also, what will happen in the discussed case? Say I enter ddb, get
confused/frustrated, go to grab a coffee to think on things, then come
back 30 minutes later? Will ntpd be happy when it sees a sudden 30 minute
jump in network time (folks on icb said no)? So even if I started ntpd, it
won't necessarily be fixing the time before reboot, so I can be saving a
bad time.

Yes, I can certainly interveen in this case and fix things up. And if I
REALLY cared about time, I would. But the example shows that there are
times where even with ntpd around, we might not want to change the RTC.

So it sounds like a kernel option is best, and folks can enable/disable
the clock write-back as desired.

Take care,

Bill