[lkml]   [2005]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectNeed better is_better_time_interpolator() algorithm

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 Williamson HP Linux & Open Source Lab

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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