Subject: Re: hardware clock 'corrupted' by ddb (and possibly other things)
To: Bill Studenmund <wrstuden@netbsd.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: tech-kern
Date: 07/10/2002 19:19:01
First: David, if there was anything attacking or personal in my
response, you have my apologies. I did not intend to.

My level of `really care' is a lot coarser than PPS synch.  More like
synched closely enough that make over NFS, using program-generators
(yacc, lex, ...) doesn't run into clock-skew problems. That was `about
a second' in the mid-90s.  With compile speed on 2GHz CPUs and gigabit
NICs, it's now under a second.

For stuck-at-ddb prompt; unless I am woefully misremembering, NTP can
be configured to recognize what it usually considers ``insane'' clock
discrepancies, and if it sees one, to jump the clock back to something
it considers sane. (this came up on comp.protocols.time.ntp when one
major vendor had a Y2k-style bug in early 2002.)

NTP is tolerant (or intolerant) of the sit-at-ddb prompt, as it is of
laptops which tinker with the CPU frequency underneath its back.
It's not as hopeless as portrayed.

But to steal a line from Pterry, "if your idea of accuracy is ``around
two-ish''", then David's scheme may have merit.


>But the example shows that there are
>times where even with ntpd around, we might not want to change the RTC.

I don't agree that the example shows that. A well-tempered NTP setup
is going to (a) recogjse the clock an `ntpdate' at next boot --
precisely in case the RTC time is way out of kilter, or the battery
died -- before starting ntpd.  If configured to jump the clock, NTPD
will do just fine.


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

On NetBSD/pmax the RTC has to be ``time in a five-year window''
betweern 1970-1976 or thereabouts (I forget the exact values; sometime
overlapping the Nixon administration), and refuses to auto-boot if
outside that range.  You don't want to ever disable writeback on that
arch, cause it'll eventully let your clock drift into no-no land.

OTOH, disabling kernel time -> RTC writeback, plus a timejump-tolerant
NTP setup, might improve life for users who dual-boot into windows98
(at least if they have NTP service when booting into NetBSD).

... Okay, I buy *that* one.