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 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.