Re: Dual core Athlons and unsynced TSCs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2006-01-13 at 10:16 -0800, [email protected] wrote:
> On Fri, Jan 13, 2006 at 12:58:36PM -0500, Lee Revell wrote:
> > > If your BIOS has an ACPI "HPET" table, then the kernel can use the HPET
> > > timer instead.  It doesn't solve the problem for apps or other kernel bits
> > > that use rdtsc directly, but there are other fixes for that floating
> > > around which will hopefully get consideration when they're mature.
> > 
> > The apps can be converted to use clock_gettime(), but that does not help
> > if the kernel can't keep reasonable time on these machines. 
> 
> Some apps/users need higher resolution and lower overhead that only rdtsc
> can offer currently.
> 

But obviously if the TSC gives wildly inaccurate results, it cannot be
used no matter how low the overhead.

> > But if we just use "clock=pmtmr" by default on these machines the TSC is
> > not a problem right?
> 
> I never tried it with pmtimer, we had HPET available.  Empirically TSC did
> not work (and we had a simple test case to show how bad it could get).
> HPET made that go away for users of gettimeofday().
> 
> We're exploring rdtsc-compatible solutions.
> 

Since timekeeping on these machines has always been completely broken,
shouldn't the default time source have been changed to the PM timer or
HPET as soon as the problem was known?

Lee

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux