Re: RTC subsystem and fractions of seconds

Re: RTC subsystem and fractions of seconds

[David Brownell]

>  	Those rtc's actually have a 1/100th of second
> register.  Should the generic rtc interface not support that?

Are you implying a new userspace API, or just an in-kernel update?

Either way, that raises the question of what other features should
be included.  What sub-second precision?  Multiple alarms?  Ways
to manage output clocks?  Sub-HZ periodic alarms?

Re: RTC subsystem and fractions of seconds

[Philippe De Muyter]

On Fri, Jan 05, 2007 at 07:49:00PM -0800, David Brownell wrote:
> >  	Those rtc's actually have a 1/100th of second
> > register.  Should the generic rtc interface not support that?
> 
> Are you implying a new userspace API, or just an in-kernel update?

My only concern at the moment is initializing linux's timeofday from the rtc
quickly and with a good precision.  The way it is done currently
in drivers/rtc/hctosys.c is 0.5 sec off.  We could obtain a much better
precision by looping there until the next change (next second for old clocks,
next 0.01 second for m41t81, maybe even better for other ones).

> 
> Either way, that raises the question of what other features should
> be included.  What sub-second precision?  Multiple alarms?  Ways
> to manage output clocks?  Sub-HZ periodic alarms?

I cannot answer that, but others may have other needs.

Philippe
-- 

Re: RTC subsystem and fractions of seconds

[David Brownell]

On Saturday 06 January 2007 3:26 pm, Philippe De Muyter wrote:
> On Fri, Jan 05, 2007 at 07:49:00PM -0800, David Brownell wrote:
> > >  	Those rtc's actually have a 1/100th of second
> > > register.  Should the generic rtc interface not support that?
> > 
> > Are you implying a new userspace API, or just an in-kernel update?
> 
> My only concern at the moment is initializing linux's timeofday from the rtc
> quickly and with a good precision. 

There will necessarily be a bit of fuzz there since it can take time to
get that RTC's mutex, and the task setting that time can be preempted.
Plus, there can also be delays at the I2C or SPI transaction level.


> The way it is done currently 
> in drivers/rtc/hctosys.c is 0.5 sec off.  We could obtain a much better
> precision by looping there until the next change (next second for old clocks,
> next 0.01 second for m41t81, maybe even better for other ones).

Hmm ... "looping" fights against "quickly"; as would "wait for next
update IRQ" (on RTCs that support that).  But it would improve precision,
at least in the sense of having the system clock and that RTC spending
less time with the lowest "seconds" digit disagreeing.

This is something you could write a patch for, n'est-ce pas?

- Dave

Re: RTC subsystem and fractions of seconds

[Hugh Dickins]

On Sat, 6 Jan 2007, David Brownell wrote:
> On Saturday 06 January 2007 3:26 pm, Philippe De Muyter wrote:
> 
> > The way it is done currently 
> > in drivers/rtc/hctosys.c is 0.5 sec off.  We could obtain a much better
> > precision by looping there until the next change (next second for old clocks,
> > next 0.01 second for m41t81, maybe even better for other ones).
> 
> Hmm ... "looping" fights against "quickly"; as would "wait for next
> update IRQ" (on RTCs that support that).  But it would improve precision,
> at least in the sense of having the system clock and that RTC spending
> less time with the lowest "seconds" digit disagreeing.
> 
> This is something you could write a patch for, n'est-ce pas?

If you're thinking of going that way, it'd be courteous to CC Matt,
who devoted some effort to removing just that loop in 2.6.17 ;)

Hugh

Re: RTC subsystem and fractions of seconds

[David Brownell]

> > Hmm ... "looping" fights against "quickly"; as would "wait for next
> > update IRQ" (on RTCs that support that).  But it would improve precision,
> > at least in the sense of having the system clock and that RTC spending
> > less time with the lowest "seconds" digit disagreeing.
> > 
> > This is something you could write a patch for, n'est-ce pas?
>
> If you're thinking of going that way,

Philippe seemed to be ...


>	it'd be courteous to CC Matt,
> who devoted some effort to removing just that loop in 2.6.17 ;)

Hmm ... "git whatchanged drivers/rtc/hctosys.c" shows no such change.
So I can't find any record of such a change or its rationale.


- dave

Re: RTC subsystem and fractions of seconds

[Hugh Dickins]

On Sat, 6 Jan 2007, David Brownell wrote:
> > > Hmm ... "looping" fights against "quickly"; as would "wait for next
> > > update IRQ" (on RTCs that support that).  But it would improve precision,
> > > at least in the sense of having the system clock and that RTC spending
> > > less time with the lowest "seconds" digit disagreeing.
> > > 
> > > This is something you could write a patch for, n'est-ce pas?
> >
> > If you're thinking of going that way,
> 
> Philippe seemed to be ...
> 
> >	it'd be courteous to CC Matt,
> > who devoted some effort to removing just that loop in 2.6.17 ;)
> 
> Hmm ... "git whatchanged drivers/rtc/hctosys.c" shows no such change.
> So I can't find any record of such a change or its rationale.

Perhaps I'm muddled - I was thinking of this and its associates:

commit 63732c2f37093d63102d53e70866cf87bf0c0479
Author: Matt Mackall <mpm@selenic.com>
Date:   Tue Mar 28 01:55:58 2006 -0800

    [PATCH] RTC: Remove RTC UIP synchronization on x86
    
    Reading the CMOS clock on x86 and some other arches currently takes up to one
    second because it synchronizes with the CMOS second tick-over.  This delay
    shows up at boot time as well a resume time.
    
    This is the currently the most substantial boot time delay for machines that
    are working towards instant-on capability.  Also, a quick back of the envelope
    calculation (.5sec * 2M users * 1 boot a day * 10 years) suggests it has cost
    Linux users in the neighborhood of a million man-hours.
    
    An earlier thread on this topic is here:
    
    http://groups.google.com/group/linux.kernel/browse_frm/thread/8a24255215ff6151/2aa97e66a977653d?hl=en&lr=&ie=UTF-8&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3D1To2R-2S7-11%40gated-at.bofh.it#2aa97e66a977653d
    
    ..from which the consensus seems to be that it's no longer desirable.
    
    In my view, there are basically four cases to consider:
    
    1) networked, need precise walltime: use NTP
    2) networked, don't need precise walltime: use NTP anyway
    3) not networked, don't need sub-second precision walltime: don't care
    4) not networked, need sub-second precision walltime:
       get a network or a radio time source because RTC isn't good enough anyway
    
    So this patch series simply removes the synchronization in favor of a simple
    seqlock-like approach using the seconds value.
    
    Note that for purposes of timer accuracy on wakeup, this patch will cause us
    to fire timers up to one second late.  But as the current timer resume code
    will already sync once (or more!), it's no worse for short timers.
    
    Signed-off-by: Matt Mackall <mpm@selenic.com>
    Cc: Andi Kleen <ak@muc.de>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Russell King <rmk@arm.linux.org.uk>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: Paul Mundt <lethal@linux-sh.org>
    Cc: Kazumoto Kojima <kkojima@rr.iij4u.or.jp>
    Cc: Alessandro Zummo <a.zummo@towertech.it>
    Signed-off-by: Andrew Morton <akpm@osdl.org>
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>

diff --git a/include/asm-i386/mach-default/mach_time.h b/include/asm-i386/mach-default/mach_time.h
index b749aa4..ff03cf0 100644
--- a/include/asm-i386/mach-default/mach_time.h
+++ b/include/asm-i386/mach-default/mach_time.h
@@ -82,21 +82,8 @@ static inline int mach_set_rtc_mmss(unsi
 static inline unsigned long mach_get_cmos_time(void)
 {
 	unsigned int year, mon, day, hour, min, sec;
-	int i;
 
-	/* The Linux interpretation of the CMOS clock register contents:
-	 * When the Update-In-Progress (UIP) flag goes from 1 to 0, the
-	 * RTC registers show the second which has precisely just started.
-	 * Let's hope other operating systems interpret the RTC the same way.
-	 */
-	/* read RTC exactly on falling edge of update flag */
-	for (i = 0 ; i < 1000000 ; i++)	/* may take up to 1 second... */
-		if (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP)
-			break;
-	for (i = 0 ; i < 1000000 ; i++)	/* must try at least 2.228 ms */
-		if (!(CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP))
-			break;
-	do { /* Isn't this overkill ? UIP above should guarantee consistency */
+	do {
 		sec = CMOS_READ(RTC_SECONDS);
 		min = CMOS_READ(RTC_MINUTES);
 		hour = CMOS_READ(RTC_HOURS);
@@ -104,6 +91,7 @@ static inline unsigned long mach_get_cmo
 		mon = CMOS_READ(RTC_MONTH);
 		year = CMOS_READ(RTC_YEAR);
 	} while (sec != CMOS_READ(RTC_SECONDS));
+
 	if (!(CMOS_READ(RTC_CONTROL) & RTC_DM_BINARY) || RTC_ALWAYS_BCD)
 	  {
 	    BCD_TO_BIN(sec);

Re: RTC subsystem and fractions of seconds

[Philippe De Muyter]

On Sat, Jan 06, 2007 at 03:52:43PM -0800, David Brownell wrote:
> On Saturday 06 January 2007 3:26 pm, Philippe De Muyter wrote:
> > On Fri, Jan 05, 2007 at 07:49:00PM -0800, David Brownell wrote:
> > > >  	Those rtc's actually have a 1/100th of second
> > > > register.  Should the generic rtc interface not support that?
> > > 
> > > Are you implying a new userspace API, or just an in-kernel update?
> > 
> > My only concern at the moment is initializing linux's timeofday from the rtc
> > quickly and with a good precision. 
> 
> There will necessarily be a bit of fuzz there since it can take time to
> get that RTC's mutex, and the task setting that time can be preempted.
> Plus, there can also be delays at the I2C or SPI transaction level.
> 
> 
> > The way it is done currently 
> > in drivers/rtc/hctosys.c is 0.5 sec off.  We could obtain a much better
> > precision by looping there until the next change (next second for old clocks,
> > next 0.01 second for m41t81, maybe even better for other ones).
> 
> Hmm ... "looping" fights against "quickly"; as would "wait for next
> update IRQ" (on RTCs that support that).  But it would improve precision,
> at least in the sense of having the system clock and that RTC spending
> less time with the lowest "seconds" digit disagreeing.
> 
> This is something you could write a patch for, n'est-ce pas?

That would require changing the interface provided by the rtc class, but
I'll look at it.

> 
> - Dave
> 
> 

-- 

Re: RTC subsystem and fractions of seconds

[Philippe De Muyter]

On Fri, Jan 05, 2007 at 07:49:00PM -0800, David Brownell wrote:
> >  	Those rtc's actually have a 1/100th of second
> > register.  Should the generic rtc interface not support that?
> 
> Are you implying a new userspace API, or just an in-kernel update?
> 
> Either way, that raises the question of what other features should
> be included.  What sub-second precision?  Multiple alarms?  Ways
> to manage output clocks?  Sub-HZ periodic alarms?

One usefull addition for my needs and with a m41t81 is the support of
the calibration of the rtc.  However this can perhaps be hidden in the
.set_mmss function.

Philippe

-- 

Re: RTC subsystem and fractions of seconds

[David Brownell]

On Sunday 07 January 2007 2:14 am, Philippe De Muyter wrote:
> On Fri, Jan 05, 2007 at 07:49:00PM -0800, David Brownell wrote:
> > >  	Those rtc's actually have a 1/100th of second
> > > register.  Should the generic rtc interface not support that?
> > 
> > Are you implying a new userspace API, or just an in-kernel update?
> > 
> > Either way, that raises the question of what other features should
> > be included.  What sub-second precision?  Multiple alarms?  Ways
> > to manage output clocks?  Sub-HZ periodic alarms?
> 
> One usefull addition for my needs and with a m41t81 is the support of
> the calibration of the rtc.  However this can perhaps be hidden in the
> .set_mmss function.

Doesn't seem like an set_mmss() mechanism at all.  Some drivers give
sysfs access to an oscillator "trim" mechanism.  What tools do you
have which track how far off that crystal is?

- Dave

Re: RTC subsystem and fractions of seconds

[Philippe De Muyter]

On Sun, Jan 07, 2007 at 06:10:30PM -0800, David Brownell wrote:

> > One usefull addition for my needs and with a m41t81 is the support of
> > the calibration of the rtc.  However this can perhaps be hidden in the
> > .set_mmss function.
> 
> Doesn't seem like an set_mmss() mechanism at all.  Some drivers give
> sysfs access to an oscillator "trim" mechanism.  What tools do you
> have which track how far off that crystal is?

ntp, either from network or from a radio-clock

and using set_mmss for that purpose seems not so disgusting, because :

- writing to the clock (the expected work of set_mmss) must be disabled when
we observe the clock drift
- set_mmss is always called with a very good precision, so one could
use the time given to set_mmss to compare it to the time given by the RTC
over a long enough period of time (more than 11 minutes) to compute the RTC's
drift and the necessary adjustment.

Of course, if we want something that is not based on ntp, then we may not
overload set_mmss.

Philippe

Re: RTC subsystem and fractions of seconds

[Philippe De Muyter]

On Sun, 7 Jan 2007, Hugh Dickins wrote:
> Author: Matt Mackall <mpm@selenic.com>
> 
>     [PATCH] RTC: Remove RTC UIP synchronization on x86
>     
>     Reading the CMOS clock on x86 and some other arches currently takes up to one
>     second because it synchronizes with the CMOS second tick-over.  This delay
>     shows up at boot time as well a resume time.

That is true if kernel's idea of an RTC's precision is 1 second.  With better
RTC's (e.g. m41t81) this delay can be reduced to 0.01 second, which is
acceptable IMHO in the boot phase.  That needs however changes in the kernel
interface to RTC's :

    - read_time should take a new parameter *nsec (or struct rtc_time should
    contain a new nsec field, so that the RTC can report its complete time
    information to the kernel.

    - struct rtc_device (or rtc_class_ops with another name) should contain
    a new field giving the RTC's resolution in nsecs, if we want to avoid the
    loop, but do not want our 0.01 second precision be destructed by always
    adding 0.5 second in rtc_hctosys
    
Philippe

RTC subsystem and fractions of seconds

[Philippe De Muyter]

Hi all,

A comment in driver/rtc/hctosys says :

    /* IMPORTANT: the RTC only stores whole seconds. It is arbitrary
     * whether it stores the most close value or the value with partial
     * seconds truncated. However, it is important that we use it to store
     * the truncated value. This is because otherwise it is necessary,
     * in an rtc sync function, to read both xtime.tv_sec and
     * xtime.tv_nsec. On some processors (i.e. ARM), an atomic read
     * of >32bits is not possible. So storing the most close value would
     * slow down the sync API. So here we have the truncated value and
     * the best guess is to add 0.5s.
     */

I work with ST m41t81 rtc's.  Those rtc's actually have a 1/100th of second
register.  Should the generic rtc interface not support that ? 

Philippe
--