Re: RTC subsystem and fractions of seconds
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RTC subsystem and fractions of seconds
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RTC subsystem and fractions of seconds
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RTC subsystem and fractions of seconds
On Sun, 7 Jan 2007, Hugh Dickins wrote: > Author: Matt Mackall <[EMAIL PROTECTED]> > > [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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RTC subsystem and fractions of seconds
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 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RTC subsystem and fractions of seconds
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 > > -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RTC subsystem and fractions of seconds
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 <[EMAIL PROTECTED]>
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==UTF-8=1=/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 <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: "David S. Miller" <[EMAIL PROTECTED]>
Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Cc: Paul Mackerras <[EMAIL PROTECTED]>
Cc: Russell King <[EMAIL PROTECTED]>
Cc: Ralf Baechle <[EMAIL PROTECTED]>
Cc: Paul Mundt <[EMAIL PROTECTED]>
Cc: Kazumoto Kojima <[EMAIL PROTECTED]>
Cc: Alessandro Zummo <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
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 < 100 ; i++) /* may take up to 1 second... */
- if (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP)
- break;
- for (i = 0 ; i < 100 ; 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);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Re: RTC subsystem and fractions of seconds
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 [EMAIL PROTECTED]
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=enlr=ie=UTF-8rnum=1prev=/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 [EMAIL PROTECTED]
Cc: Andi Kleen [EMAIL PROTECTED]
Cc: David S. Miller [EMAIL PROTECTED]
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Cc: Paul Mackerras [EMAIL PROTECTED]
Cc: Russell King [EMAIL PROTECTED]
Cc: Ralf Baechle [EMAIL PROTECTED]
Cc: Paul Mundt [EMAIL PROTECTED]
Cc: Kazumoto Kojima [EMAIL PROTECTED]
Cc: Alessandro Zummo [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
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 100 ; i++) /* may take up to 1 second... */
- if (CMOS_READ(RTC_FREQ_SELECT) RTC_UIP)
- break;
- for (i = 0 ; i 100 ; 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);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Re: RTC subsystem and fractions of seconds
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 -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RTC subsystem and fractions of seconds
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 -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RTC subsystem and fractions of seconds
On Sun, 7 Jan 2007, Hugh Dickins wrote: Author: Matt Mackall [EMAIL PROTECTED] [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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RTC subsystem and fractions of seconds
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RTC subsystem and fractions of seconds
> > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RTC subsystem and fractions of seconds
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RTC subsystem and fractions of seconds
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RTC subsystem and fractions of seconds
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 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RTC subsystem and fractions of seconds
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 -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RTC subsystem and fractions of seconds
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RTC subsystem and fractions of seconds
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RTC subsystem and fractions of seconds
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RTC subsystem and fractions of seconds
> 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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RTC subsystem and fractions of seconds
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 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RTC subsystem and fractions of seconds
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 -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RTC subsystem and fractions of seconds
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? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
