[lkml]   [2005]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Need better is_better_time_interpolator() algorithm
On Thu, 2005-08-25 at 10:44 -0600, Alex Williamson wrote:
> 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,

With my timeofday rework code, the timesource structure (which was
influenced by the time interpolators) just uses a fixed "priority" vale.
This value can be changed as needed (for example: We lower the tsc
timesource priority if the TSCs are found to be out of sync).

In order to have some scale of goodness and avoid priority inflation, I
put a comment suggesting what the different priority levels mean.

0-99: Terrible. Only use at bootup or when there's nothing else
100-199: Functional but not desired
200-299: Good. a correct and usable timesource
300-399: Desired. A reasonably fast and accurate timesource.
400-499: Perfect. The ideal timesource. A must-use where available.

Additionally, I created a sysfs interface that could be used to override
the priority selected timesource.

Realistically I don't think too many systems will have multiple out of
tree timesources, so assigning the correct priority value shouldn't be
too difficult.

This just seemed a bit more straight forward then sorting out some
weighting algorithm for their properties to select the best timesource.


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 19:41    [W:0.039 / U:0.100 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site