From: Chris Friesen <cfriesen@nortel.com>
To: Nishanth Aravamudan <nacc@us.ibm.com>
Cc: george@mvista.com, john stultz <johnstul@us.ibm.com>,
Liu Qi <liuqi@ict.ac.cn>,
"'high-res-timers-discourse@lists.sourceforge.net'"
<high-res-timers-discourse@lists.sourceforge.net>,
Darren Hart <dvhltc@us.ibm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Help with the high res timers
Date: Wed, 04 May 2005 12:16:00 -0600 [thread overview]
Message-ID: <42791160.7090905@nortel.com> (raw)
In-Reply-To: <20050504175151.GA2698@us.ibm.com>
Nishanth Aravamudan wrote:
> If I understand your point correctly, I think this is achieved by
> TIMERINTERVAL_BITS in my patch (not to claim my patch is function, but
> conceptually). No matter what you actually request, the best you can do
> is 2^TIMERINTERVAL_BITS nanoseconds, and usually worse because the
> tick-rate and timerinterval length do not necessarily line up.
My point is simply that the timer for the next interval should start at
the time the timer expires, not the time that userspace picks up the
prior expiration. Throttling the timer rate should be done at the time
of timer request rather than timer expiry.
If I have usec-accuracy in the timer subsystem, I should be able to set
a timer with an interval of 9.999ms and have it remain accurate over
time (subject to scheduler jitter, of course). N timer intervals later
my timer should expire at (original_time + N*9.999ms + jitter). In this
case the error is roughly constant with time.
If the timer doesn't start counting the next interval until the user
detects expiry, I'm going to get some non-zero addition to *each*
interval such that my timers will not remain accurate over long periods
of time. In this case N timer intervals later my timer will expire at
(original_time + N*(9.999ms + jitter)) which is a very different thing.
Since jitter will always be positive, the error increases with time.
Chris
next prev parent reply other threads:[~2005-05-04 18:17 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E1DSl7F-0002v2-Ck@sc8-sf-web4.sourceforge.net>
[not found] ` <20050503024336.GA4023@ict.ac.cn>
[not found] ` <4277EEF7.8010609@mvista.com>
[not found] ` <1115158804.13738.56.camel@cog.beaverton.ibm.com>
[not found] ` <427805F8.7000309@mvista.com>
[not found] ` <20050504001307.GF3372@us.ibm.com>
2005-05-04 17:10 ` Help with the high res timers George Anzinger
2005-05-04 17:44 ` Chris Friesen
2005-05-04 17:51 ` Nishanth Aravamudan
2005-05-04 18:16 ` Chris Friesen [this message]
2005-05-04 20:36 ` George Anzinger
2005-05-04 20:31 ` George Anzinger
2005-05-04 18:14 ` Darren Hart
2005-05-04 21:46 ` George Anzinger
[not found] ` <1115166592.13738.96.camel@cog.beaverton.ibm.com>
2005-05-04 17:46 ` George Anzinger
2005-05-04 22:13 ` john stultz
2005-05-04 22:48 ` George Anzinger
2005-05-04 23:27 ` john stultz
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=42791160.7090905@nortel.com \
--to=cfriesen@nortel.com \
--cc=dvhltc@us.ibm.com \
--cc=george@mvista.com \
--cc=high-res-timers-discourse@lists.sourceforge.net \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=liuqi@ict.ac.cn \
--cc=nacc@us.ibm.com \
/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