From: bryanh@giraffe-data.com (Bryan Henderson)
To: alessandro.zummo@towertech.it
Cc: mpm@selenic.com, benh@kernel.crashing.org, ak@muc.de,
akpm@osdl.org, torvalds@osdl.org, davem@davemloft.net,
kkojima@rr.iij4u.or.jp, lethal@linux-sh.org, paulus@samba.org,
ralf@linux-mips.org, rmk@arm.linux.org.uk,
linux-kernel@vger.kernel.org, smurf@debian.org,
stenn@whimsy.udel.edu, bunk@stusta.de, lamont@debian.org
Subject: Re: 11 minute RTC update (was Re: Remove RTC UIP)
Date: 29 Mar 2006 16:49:41 +0000 [thread overview]
Message-ID: <52304.bryanh@giraffe-data.com> (raw)
In-Reply-To: <20060329034555.11785044@inspiron> (alessandro.zummo@towertech.it)
> I think it isn't. Ideally ntpd should open /dev/rtcX and write the
> time, but I'm not sure if it belongs to it or if a simple
> hwclock --systohc /dev/rtcX should be used.
It makes a lot more sense to use hwclock than to duplicate its
function in ntpd. Besides the downside of having to maintain two
programs that do the same thing, it creates a difficult interaction
problem if a user uses both, because hwclock tries to work with the
systematic drift rate of the clock, and if hwclock is not the only
thing setting it, it can get all messed up. hwclock contains special
code today to notice that the kernel is interfering (adjtimex()
reports that information), but it really would rather not, and I think
it would be even messier if the interference came from outside the
kernel.
I'm not sure ntpd even should be involved with this. It seems to me
cleaner to keep maintaining of the Linux clock and maintaining of the
hardware clock separate. On my own system, I simply have cron do a
hwclock --systohc once a week, independent of what keeps the system
clock accurate. Some people do it at shutdown time as well. (You
don't have to set the clock every 11 minutes if you're keeping track
of systematic drift like hwclock does).
Concerning migration: ntpd presently tells the kernel to go into 11
minute mode (I think technically, it tells the kernel that it is
keeping the system time accurate and based on that information, the
kernel takes the opportunity to keep the hardware clock accurate as
well, but I think it's practically equivalent). So that suggests a
migration path: Step 1: ntpd stops using that flag; Step 2: kernel
issues warning if someone uses the flag; Step 3: kernel ignores the
flag. For 1), ntpd issues a warning that nobody's minding the
hardware clock unless you pass an option telling it to do hwclock
--systohc or that you're handling the issue and ntpd needn't warn you
about it. I like the latter better.
BTW, I am the maintainer of hwclock. This is the first I've heard of
this discussion, but I have always been a supporter of the kernel
getting out of the hardware clock maintenance business. What's this
about multiple RTC's?
--
Bryan Henderson Phone 408-621-2000
San Jose, California
next prev parent reply other threads:[~2006-03-29 17:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200603270920.k2R9KYYx007214@shell0.pdx.osdl.net>
[not found] ` <20060327111836.GA79131@muc.de>
[not found] ` <20060327163218.GD3642@waste.org>
[not found] ` <20060327190037.GB27030@muc.de>
[not found] ` <20060327211143.55ef7c4e@inspiron>
[not found] ` <1143512075.2284.2.camel@localhost.localdomain>
[not found] ` <20060329000215.683eb2d5@inspiron>
2006-03-29 0:03 ` 11 minute RTC update (was Re: Remove RTC UIP) Matt Mackall
2006-03-29 1:11 ` Alessandro Zummo
2006-03-29 1:21 ` Matt Mackall
2006-03-29 1:45 ` Alessandro Zummo
2006-03-29 16:49 ` Bryan Henderson [this message]
2006-03-29 18:07 ` Alessandro Zummo
2006-03-30 3:51 ` Bryan Henderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52304.bryanh@giraffe-data.com \
--to=bryanh@giraffe-data.com \
--cc=ak@muc.de \
--cc=akpm@osdl.org \
--cc=alessandro.zummo@towertech.it \
--cc=benh@kernel.crashing.org \
--cc=bunk@stusta.de \
--cc=davem@davemloft.net \
--cc=kkojima@rr.iij4u.or.jp \
--cc=lamont@debian.org \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.com \
--cc=paulus@samba.org \
--cc=ralf@linux-mips.org \
--cc=rmk@arm.linux.org.uk \
--cc=smurf@debian.org \
--cc=stenn@whimsy.udel.edu \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.