Messages in this thread | | | Subject | Re: Need better is_better_time_interpolator() algorithm | From | Alex Williamson <> | Date | Thu, 25 Aug 2005 12:43:25 -0600 |
| |
On Thu, 2005-08-25 at 10:36 -0700, john stultz wrote: > On Thu, 2005-08-25 at 10:44 -0600, Alex Williamson wrote: > > 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. ... > 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.
I don't know that it's that uncommon. Simply having one non-arch specific timer is enough to need to decided whether it's better than a generic timer. I assume pretty much every arch has a cycle timer. For smaller boxes, this might be the preferred timer given it's latency even if something like an hpet exists (mmio access are expensive). How do you hard code a value that can account for that? I agree, we could easily go too far and produce some bloated algorithm, but maybe it's simply a weighted product of a few variables.
To start with, what would this do:
(frequency) * (1/drift) * (1/latency) * (1/(jitter_factor * cpus))
Something this simple at least starts to dynamically bring the factors together. All else being equal (and with no weighting), this would give the 1.5GHz/750ppm timer a higher priority than the 250MHz/500ppm timer. Is that good? I like your idea to make this user tunable after boot, but I still think there has to be a way to make a smarter decision up front. 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/
| |