11 minute RTC update (was Re: Remove RTC UIP)

11 minute RTC update (was Re: Remove RTC UIP)

[Matt Mackall]

[linux-kernel cc:ed]

On Wed, Mar 29, 2006 at 12:02:15AM +0200, Alessandro Zummo wrote:
> On Tue, 28 Mar 2006 13:14:34 +1100
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> 
> > >  While we are on the topic, I would like to ask everyone about
> > >  the 11 min ntp/rtc update feature of the kernel.
> > > 
> > >  It is something that makes sense to move to
> > >  userland?
> > 
> > YES !!! :)
> 
>  great! given that it is not implemented in the new RTC subsystem
>  and nobody objected, I will not add it :)

I agree that this should be migrated to userspace, but I'm more
worried about the functionality impact here than for the UIP case.

With existing NTP setups, and the kernel no longer writing to the RTC,
you might have the RTC drift far enough that NTP failed to sync on the
next boot. (Correct me if I'm wrong, of course.)

-- 
Mathematics is the supreme nostalgia of our time.

Re: 11 minute RTC update (was Re: Remove RTC UIP)

[Alessandro Zummo]

On Tue, 28 Mar 2006 18:03:45 -0600
Matt Mackall <mpm@selenic.com> wrote:

> > > >  While we are on the topic, I would like to ask everyone about
> > > >  the 11 min ntp/rtc update feature of the kernel.
> > > > 
> > > >  It is something that makes sense to move to
> > > >  userland?
> > > 
> > > YES !!! :)
> > 
> >  great! given that it is not implemented in the new RTC subsystem
> >  and nobody objected, I will not add it :)
> 
> I agree that this should be migrated to userspace, but I'm more
> worried about the functionality impact here than for the UIP case.
> 
> With existing NTP setups, and the kernel no longer writing to the RTC,
> you might have the RTC drift far enough that NTP failed to sync on the
> next boot. (Correct me if I'm wrong, of course.)

 That's probably true, I'm not expert on the matter. The new subsystem only
 covers platforms that were not covered before (i.e. without external patches),
 so that this should not impact users because the NTP update mode
 was not working on them.

 The problem might arise when other RTC drivers (i.e. x86) will be converted
 and deployed.

 We need a migration plan. Any suggestion? 

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Turin, Italy

  http://www.towertech.it

Re: 11 minute RTC update (was Re: Remove RTC UIP)

[Matt Mackall]

On Wed, Mar 29, 2006 at 03:11:02AM +0200, Alessandro Zummo wrote:
> On Tue, 28 Mar 2006 18:03:45 -0600
> Matt Mackall <mpm@selenic.com> wrote:
> 
> > > > >  While we are on the topic, I would like to ask everyone about
> > > > >  the 11 min ntp/rtc update feature of the kernel.
> > > > > 
> > > > >  It is something that makes sense to move to
> > > > >  userland?
> > > > 
> > > > YES !!! :)
> > > 
> > >  great! given that it is not implemented in the new RTC subsystem
> > >  and nobody objected, I will not add it :)
> > 
> > I agree that this should be migrated to userspace, but I'm more
> > worried about the functionality impact here than for the UIP case.
> > 
> > With existing NTP setups, and the kernel no longer writing to the RTC,
> > you might have the RTC drift far enough that NTP failed to sync on the
> > next boot. (Correct me if I'm wrong, of course.)
> 
>  That's probably true, I'm not expert on the matter. The new subsystem only
>  covers platforms that were not covered before (i.e. without external patches),
>  so that this should not impact users because the NTP update mode
>  was not working on them.
> 
>  The problem might arise when other RTC drivers (i.e. x86) will be converted
>  and deployed.
> 
>  We need a migration plan. Any suggestion? 

I guess the question then becomes: is existing userspace (ntpd)
already doing its own updates. If so, we can schedule the feature for
removal in the near future. If not, it may take quite a bit longer.

-- 
Mathematics is the supreme nostalgia of our time.

Re: 11 minute RTC update (was Re: Remove RTC UIP)

[Alessandro Zummo]

On Tue, 28 Mar 2006 19:21:37 -0600
Matt Mackall <mpm@selenic.com> wrote:

> > > With existing NTP setups, and the kernel no longer writing to the RTC,
> > > you might have the RTC drift far enough that NTP failed to sync on the
> > > next boot. (Correct me if I'm wrong, of course.)
> > 
> >  That's probably true, I'm not expert on the matter. The new subsystem only
> >  covers platforms that were not covered before (i.e. without external patches),
> >  so that this should not impact users because the NTP update mode
> >  was not working on them.
> > 
> >  The problem might arise when other RTC drivers (i.e. x86) will be converted
> >  and deployed.
> > 
> >  We need a migration plan. Any suggestion? 
> 
> I guess the question then becomes: is existing userspace (ntpd)
> already doing its own updates. If so, we can schedule the feature for
> removal in the near future. If not, it may take quite a bit longer.

 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.

 Obviously hwclock needs to be updated to support multiple RTCs.

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Turin, Italy

  http://www.towertech.it

Re: 11 minute RTC update (was Re: Remove RTC UIP)

[Bryan Henderson]

> 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

Re: 11 minute RTC update (was Re: Remove RTC UIP)

[Alessandro Zummo]

On 29 Mar 2006 16:49:41 +0000
bryanh@giraffe-data.com (Bryan Henderson) wrote:

> 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.

 I agree with the latter option. I can write a patch for the kernel
 to issue the warning.
 
> 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?

 with the new subsystem that has recently been introduced you can
 have more than one clock. the first one is /dev/rtc0 . udev
 will make a link from /dev/rtc to /dev/rtc0, but it would be
 fine if hwclock can check /dev/rtc0 itself in no device is specified
 on the cmd line.

 One can have a mix of I2C clocks, x86 and maybe external radio
 syncronized clocks all in the same subsystem.
 
 But there's a problem. hwclock waits for the second
 to change before setting the time. It may happen, with some i2c clocks,
 that the oscillator is disabled and that it is started when the
 time is set. Some other devices simply hang and may be restarted only by setting
 the time.

 It would be fine if hwclock can wait for the second to change only
 for a definite amount of time and then always try to set the time.

 It may also happen that reading the time from the device returns
 a failure due to a stopped clock. hwclock should ignore the error.

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Turin, Italy

  http://www.towertech.it

Re: 11 minute RTC update (was Re: Remove RTC UIP)

[Bryan Henderson]

> udev will make a link from /dev/rtc to /dev/rtc0, but it would be
> fine if hwclock can check /dev/rtc0 itself in no device is specified
> on the cmd line.

I think one could argue as strongly that if the user has multiple
clocks and has not selected one as default by symlinking it to /dev/rtc,
then hwclock should make the user choose rather than pick one silently.

I'm ambivalent.  I'll go ahead and make hwclock use /dev/rtc0 if there's
no /dev/rtc, unless I hear more arguments for the other side.

> It would be fine if hwclock can wait for the second to change only
> for a definite amount of time and then always try to set the time.

OK.  N.B. the wait already times out, but in present code, that causes
the program to fail without setting anything.  Also the --fast option
makes hwclock simply skip the whole synchronization process (meant for
use by people who don't find subsecond precision worth two seconds of
waiting at every boot).

I'll make hwclock proceed to set the clock when the synchronization
fails, but not try to recalculate the drift rate.

-- 
Bryan Henderson                                    Phone 408-621-2000
San Jose, California