On Sat, 27 Aug 2005, Pavel Machek wrote:
> Usually is the key word here. Older APM stuff changes frequency behind
> your back, and sometimes frequency shift is time-critical.
In that case the clocks tied to the shifting frequency are
not usable.
-
To unsubscribe from this list: send the line "un
Hi!
> >Would we ever want to favor a frequency shifting timer over anything
> > else in the system? If it was noticeable perhaps we'd just need a
> > callback to re-evaluate the frequency and rescan for the best timer. If
> > it happens without notice, a flag that statically assigns it the l
Christoph Lameter wrote:
On Fri, 26 Aug 2005, Alex Williamson wrote:
Would we ever want to favor a frequency shifting timer over anything
else in the system? If it was noticeable perhaps we'd just need a
callback to re-evaluate the frequency and rescan for the best timer. If
it happens wit
On Fri, 26 Aug 2005, Alex Williamson wrote:
>Would we ever want to favor a frequency shifting timer over anything
> else in the system? If it was noticeable perhaps we'd just need a
> callback to re-evaluate the frequency and rescan for the best timer. If
> it happens without notice, a flag
On Fri, 2005-08-26 at 12:16 -0700, George Anzinger wrote:
> Alex Williamson wrote:
> > On Fri, 2005-08-26 at 08:39 -0700, Christoph Lameter wrote:
> >>1. If a system boots up with a single cpu then there is no question that
> >>the ITC/TSC should be used because of the fast access.
>
> We need t
Alex Williamson wrote:
On Fri, 2005-08-26 at 08:39 -0700, Christoph Lameter wrote:
I think a priority is something useful for the interpolators. Some of
the decisions about which time sources to use also have criteria different
from drift/latency/jitter/cpu. F.e. timers may not survive variou
On Thu, 25 Aug 2005, Alex Williamson wrote:
>I don't really know if this makes sense, but it seems to do what I
> think it should. If I where to add another node to the system, I would
> more strongly favor the HPETs time, if I removed a node I would revert
> to the cycle counter. Anyway, I
On Fri, 2005-08-26 at 08:39 -0700, Christoph Lameter wrote:
> I think a priority is something useful for the interpolators. Some of
> the decisions about which time sources to use also have criteria different
> from drift/latency/jitter/cpu. F.e. timers may not survive various
> power-saving co
On Thu, 25 Aug 2005, Alex Williamson wrote:
>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 p
On Thu, 2005-08-25 at 17:40 -0400, [EMAIL PROTECTED] wrote:
> > (frequency) * (1/drift) * (1/latency) * (1/(jitter_factor * cpus))
>
> (Note that 1/cpus, being a constant for all evaluations of this
> expression, has no effect on the final ranking.)
I was sloppy expressing how the jitter facto
> (frequency) * (1/drift) * (1/latency) * (1/(jitter_factor * cpus))
(Note that 1/cpus, being a constant for all evaluations of this
expression, has no effect on the final ranking.)
The usual way it's done is with some fiddle factors:
quality_a^a * quality_b^b * quality_c^c
Or, equivalently:
a
On Thu, 2005-08-25 at 12:43 -0600, Alex Williamson wrote:
> 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
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 o
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 ||
>
14 matches
Mail list logo
