lkml.org 
[lkml]   [2005]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectNeed better is_better_time_interpolator() algorithm
From
Date
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

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

\
 
 \ /
  Last update: 2005-08-25 18:48    [W:0.073 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site