Re: HPET vs other timers

On Sat, Jun 02, 2007 at 12:52:47PM -0700, Nate Lawson wrote:
> Kris Kennaway wrote:
> > On Mon, May 21, 2007 at 11:27:16AM -0700, Nate Lawson wrote:
> >> Dag-Erling Sm??rgrav wrote:
> >>> "Poul-Henning Kamp" <phk_at_phk.freebsd.dk> writes:
> >>>> Dag-Erling Sm??rgrav <des_at_des.no> writes:
> >>>>> "Poul-Henning Kamp" <phk_at_phk.freebsd.dk> writes:
> >>>>>> I can't rememember who raised the quality of it recently, CVS will
> >>>>>> know.  I was sceptical, because I also have systems where HPET is
> >>>>>> slow.
> >>>>> I did, with your approval, almost a year ago.
> >>>> Yes, I said "try it" or something of the sort.
> >>> For the record, I ran with HPET timers the entire time from HPET support
> >>> was first committed until I finally committed that patch - about ten
> >>> months - so I did test it to the best of my ability.
> >>>
> >>> DES
> >> Let's keep this technical.  I'm fine with bumping HPET to below ACPI
> >> timer if the hw turns out to be this much slower.
> >>
> >> Anyone able to speculate why though?  HPET only reads 32 bits from a
> >> memory mapped region.  No locking or other requirements.  ACPI_timer
> >> does multiple IO ops, which according to bde_at_ are much slower than
> >> memory reads.  So unless something from the chipset is stopping the
> >> processor (SMI?) when it reads from this region, I have a hard time
> >> seeing why it's slower.
> > 
> > I don't know what the cause is, only that it is empirically the
> > slowest of all the timers in this workload.  Can you provide
> > supporting evidence that it is fact faster than all the alternatives
> > in other workloads?
> 
> It's not the workload, it's the system.  These timers are provided by
> the chipset and enabled by the BIOS and so the behavior is
> system-dependent.  Of course, it shouldn't be that way and this should
> always be the fastest timer but when it comes to the BIOS, major
> mistakes and weird behavior are always expected.
> 
> HPET will be the main timer for Vista and is faster on at least one
> system according to this study.
> http://www.microsoft.com/whdc/system/CEC/mm-timer.mspx
> 
> More info:
> http://softwarecommunity.intel.com/isn/Community/en-US/forums/permalink/30232032/30232368/ShowThread.aspx
> 
> Perhaps we should implement profiling of all timecounters instead of a
> hard-coded quality value?

That might be a good idea.  Failing that, I'd say that we at least
need some convincing evidence that HPET is indeed fast on a suitably
large subset of existing systems.

Kris