From: George Anzinger <george@mvista.com>
To: Chris Friesen <cfriesen@nortel.com>
Cc: Nishanth Aravamudan <nacc@us.ibm.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 13:36:15 -0700 [thread overview]
Message-ID: <4279323F.1000304@mvista.com> (raw)
In-Reply-To: <42791160.7090905@nortel.com>
Chris Friesen wrote:
> 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.
You can, and we do in the main line kernel, keep this accuracy even with missed
timer expiries. When a timer is restarted, the actual requested expire time is
recalculated. It is adjusted ONLY by the requested repeat time until it results
in a time that has yet to come and the number of repeat times it takes is logged
in the overrun count for user examination.
>
> Chris
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
next prev parent reply other threads:[~2005-05-04 20:41 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
2005-05-04 20:36 ` George Anzinger [this message]
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=4279323F.1000304@mvista.com \
--to=george@mvista.com \
--cc=cfriesen@nortel.com \
--cc=dvhltc@us.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.