lkml.org 
[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
From
Date
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.

ie:
0-99: Terrible. Only use at bootup or when there's nothing else
available
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.

thanks
-john

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