From: Alex Williamson <alex.williamson@hp.com>
To: linux-kernel@vger.kernel.org
Subject: Need better is_better_time_interpolator() algorithm
Date: Thu, 25 Aug 2005 10:44:28 -0600 [thread overview]
Message-ID: <1124988269.5331.49.camel@tdi> (raw)
Hi,
In playing with an HPET device, I noticed that
kernel/timer.c:is_better_time_interpolator() is completely non-symmetric
in the timer it returns. The test is simply:
return new->frequency > 2*time_interpolator->frequency ||
(unsigned long)new->drift < (unsigned long)time_interpolator->drift;
Given two timers:
(a) 1.5GHz, 750ppm
(b) 250Mhz, 500ppm
the resulting "better" timer is completely dependent on the order
they're passed in. For example, (a),(b) = (b); (b),(a) = (a).
What are we really looking for in a "better" timer? There are at
least 4 factors that I can think of that seem important to determining a
better clock:
* resolution (frequency)
* accuracy (drift)
* access latency (may be non-uniform across the system?)
* jitter (monotonically increasing)
How can we munge these all together to come up with a single goodness
factor for comparison? There's probably a thesis covering algorithms to
handle this. Anyone know of one or have some good ideas? Thanks,
Alex
--
Alex Williamson HP Linux & Open Source Lab
next reply other threads:[~2005-08-25 16:45 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-25 16:44 Alex Williamson [this message]
2005-08-25 17:36 ` Need better is_better_time_interpolator() algorithm john stultz
2005-08-25 18:43 ` Alex Williamson
2005-08-25 19:02 ` john stultz
2005-08-26 15:39 ` Christoph Lameter
2005-08-26 16:18 ` Alex Williamson
2005-08-26 19:16 ` George Anzinger
2005-08-26 19:26 ` Alex Williamson
2005-08-26 19:33 ` Christoph Lameter
2005-08-26 19:51 ` George Anzinger
2005-08-27 11:55 ` Pavel Machek
2005-08-29 17:00 ` Christoph Lameter
-- strict thread matches above, loose matches on Subject: below --
2005-08-25 21:40 linux
2005-08-25 23:07 ` Alex Williamson
2005-08-26 16:48 ` Christoph Lameter
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=1124988269.5331.49.camel@tdi \
--to=alex.williamson@hp.com \
--cc=linux-kernel@vger.kernel.org \
/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