From: George Anzinger <george@mvista.com>
To: john stultz <johnstul@us.ibm.com>
Cc: Christoph Lameter <clameter@sgi.com>,
Albert Cahalan <albert@users.sourceforge.net>,
lkml <linux-kernel@vger.kernel.org>,
tim@physik3.uni-rostock.de, Ulrich.Windl@rz.uni-regensburg.de,
Len Brown <len.brown@intel.com>,
linux@dominikbrodowski.de, David Mosberger <davidm@hpl.hp.com>,
Andi Kleen <ak@suse.de>,
paulus@samba.org, schwidefsky@de.ibm.com, jimix@us.ibm.com,
keith maanthey <kmannth@us.ibm.com>, greg kh <greg@kroah.com>,
Patricia Gaughen <gone@us.ibm.com>,
Chris McDermott <lcm@us.ibm.com>
Subject: Re: [RFC][PATCH] new timeofday core subsystem (v.A0)
Date: Wed, 15 Sep 2004 12:58:37 -0700 [thread overview]
Message-ID: <41489EED.6090400@mvista.com> (raw)
In-Reply-To: <1095274131.29408.2990.camel@cog.beaverton.ibm.com>
john stultz wrote:
~
>
>
>>Real time features such as posix-timer's also depend on the ability to
>>deliver a signal at an exact point in time. Soft timers can only give a
>>very rough approximation in these cases.
>>
>>So I think this feature is essential.
>
>
> I think the functionality is essential, but that it doesn't belong in the time of day code.
>
> Basically we have two things we're trying to do:
>
> 1. Keep accurate time
> 2. Generate hardware interrupts accurately
>
> While frequently the same hardware can do both, not all hardware is
> usable for both functions. Thus I believe we should cleanly split these
> two subsystems. My proposal only provided the keep accurate time part,
> however one could using that functionality, to then manipulate hardware
> interrupts to ensure accuracy in the timer subsystem.
>
The thing I think is missing in all this is that, in some platforms, the
hardware to provide the interrupts is more accurate. We have, IMHO, three cases
here:
a) The interrupts are accurate but the clock info (e.g. TSC) is not.
b) The clock in accurate but the timer is not, and
c) The clock and interrupt come from the same accurate hardware source.
The X86 is in class a) in that the PIT is accurate and the TSC is not. The
muddy part here is the pm-timer which is accurate but takes a _long_ time to access.
PPCs are in class c) as are some MIPS, ARM, and PARISC. I am not sure about the
rest and can not lay my hands on one of class b).
For the class a) machines, I think the best approach is to use a clock that has
reasonable short term accuracy and to use the timer to, from time to time,
correct it. This should be on the order of an internal NTP sort of correction.
For the class a) and b) machines, I think it would be wise to not seperated the
timer and the clock so much as to make it "hard" to use one to correct the other.
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
next prev parent reply other threads:[~2004-09-15 20:02 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-02 21:07 [RFC] New Time of day proposal (updated 9/2/04) john stultz
2004-09-02 21:09 ` [RFC][PATCH] new timeofday core subsystem (v.A0) john stultz
2004-09-02 21:11 ` [RFC][PATCH] new timeofday i386 hooks (v.A0) john stultz
2004-09-02 21:12 ` [RFC][PATCH] new timeofday i386 timesources (v.A0) john stultz
2004-09-03 1:44 ` [RFC][PATCH] new timeofday i386 hooks (v.A0) George Anzinger
2004-09-03 2:06 ` john stultz
2004-09-03 8:07 ` Ulrich Windl
2004-09-03 18:09 ` George Anzinger
2004-09-02 22:19 ` [RFC][PATCH] new timeofday core subsystem (v.A0) Christoph Lameter
2004-09-02 22:28 ` john stultz
2004-09-02 22:42 ` Christoph Lameter
2004-09-02 23:14 ` john stultz
2004-09-02 23:39 ` Christoph Lameter
2004-09-03 0:07 ` john stultz
2004-09-03 0:47 ` Christoph Lameter
2004-09-03 1:30 ` john stultz
2004-09-03 7:43 ` George Anzinger
2004-09-03 19:32 ` john stultz
2004-09-03 16:18 ` Christoph Lameter
2004-09-03 21:00 ` john stultz
2004-09-03 22:04 ` Christoph Lameter
2004-09-03 23:00 ` john stultz
2004-09-04 0:11 ` Christoph Lameter
2004-09-03 1:39 ` George Anzinger
2004-09-03 1:58 ` john stultz
2004-09-03 6:42 ` Albert Cahalan
2004-09-03 7:24 ` George Anzinger
2004-09-03 19:27 ` john stultz
2004-09-03 22:10 ` George Anzinger
2004-09-03 23:32 ` john stultz
2004-09-04 0:02 ` George Anzinger
2004-09-08 18:07 ` john stultz
2004-09-09 0:08 ` George Anzinger
2004-09-09 0:51 ` john stultz
2004-09-09 3:14 ` Christoph Lameter
2004-09-09 3:32 ` john stultz
2004-09-09 4:31 ` George Anzinger
2004-09-09 6:37 ` Jesse Barnes
2004-09-09 8:09 ` George Anzinger
2004-09-09 19:07 ` john stultz
2004-09-09 20:49 ` George Anzinger
2004-09-13 21:29 ` Christoph Lameter
2004-09-13 22:25 ` john stultz
2004-09-13 22:45 ` Christoph Lameter
2004-09-14 6:53 ` Ulrich Windl
2004-09-14 17:49 ` Christoph Lameter
2004-09-15 0:57 ` George Anzinger
2004-09-15 3:32 ` Christoph Lameter
2004-09-15 8:04 ` George Anzinger
2004-09-15 8:54 ` Dominik Brodowski
2004-09-15 17:54 ` George Anzinger
2004-09-15 9:12 ` Andi Kleen
2004-09-15 15:46 ` Christoph Lameter
2004-09-15 18:00 ` George Anzinger
2004-09-15 18:28 ` Christoph Lameter
2004-09-15 6:46 ` Christoph Lameter
2004-09-15 16:32 ` john stultz
2004-09-15 16:46 ` Christoph Lameter
2004-09-15 17:13 ` john stultz
2004-09-15 17:30 ` Christoph Lameter
2004-09-15 18:48 ` john stultz
2004-09-15 19:58 ` George Anzinger [this message]
2004-09-15 20:20 ` Christoph Lameter
2004-09-16 7:02 ` Ulrich Windl
2004-09-03 19:18 ` john stultz
2004-09-02 22:09 ` [RFC] New Time of day proposal (updated 9/2/04) Christoph Lameter
2004-09-02 22:22 ` john stultz
2004-09-02 22:47 ` Christoph Lameter
2004-09-03 9:54 ` Dominik Brodowski
2004-09-03 19:41 ` john stultz
2004-09-03 20:26 ` Dominik Brodowski
2004-09-03 21:05 ` john stultz
2004-09-06 6:26 ` Ulrich Windl
2004-09-06 11:56 ` Alan Cox
2004-09-07 16:14 ` Christoph Lameter
2004-09-03 15:17 ` Andi Kleen
2004-09-03 20:11 ` john stultz
2004-09-04 13:00 ` Andi Kleen
2004-09-07 16:10 ` Christoph Lameter
2004-09-07 18:24 ` George Anzinger
2004-09-07 20:55 ` Christoph Lameter
2004-09-07 21:42 ` George Anzinger
2004-09-08 6:26 ` Ulrich Windl
2004-09-08 18:25 ` john stultz
[not found] <413850B9.15119.BA95FD@rkdvmks1.ngate.uni-regensburg.de>
[not found] ` <1094224071.431.7758.camel@cube>
2004-09-06 6:08 ` [RFC][PATCH] new timeofday core subsystem (v.A0) Ulrich Windl
2004-09-12 17:11 ` Albert Cahalan
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=41489EED.6090400@mvista.com \
--to=george@mvista.com \
--cc=Ulrich.Windl@rz.uni-regensburg.de \
--cc=ak@suse.de \
--cc=albert@users.sourceforge.net \
--cc=clameter@sgi.com \
--cc=davidm@hpl.hp.com \
--cc=gone@us.ibm.com \
--cc=greg@kroah.com \
--cc=jimix@us.ibm.com \
--cc=johnstul@us.ibm.com \
--cc=kmannth@us.ibm.com \
--cc=lcm@us.ibm.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@dominikbrodowski.de \
--cc=paulus@samba.org \
--cc=schwidefsky@de.ibm.com \
--cc=tim@physik3.uni-rostock.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox