From the Linux Kernel (make menuconfig) there seem to be two new reliable
sources for timing information. Note the remark about "Time Stamp Counter"
below. Question is, which one of these (or others) are your API functions
using ? I have absolutely no idea !
CONFIG_HPET_TIMER:
This enables the use of the HPET for the kernel's internal timer.
HPET is the next generation timer replacing legacy 8254s.
You can safely choose Y here. However, HPET will only be
activated if the platform and the BIOS support this feature.
Otherwise the 8254 will be used for timing services.
Choose N to continue using the legacy 8254 timer.
Symbol: HPET_TIMER [=y]
Prompt: HPET Timer Support
Defined at arch/i386/Kconfig:440
Location:
-> Processor type and features
CONFIG_X86_PM_TIMER:
The Power Management Timer is available on all
ACPI-capable, in most cases even if
ACPI is unusable or blacklisted.
This timing source is not affected by powermanagement
features like aggressive processor
idling, throttling, frequency and/or
voltage scaling, unlike the commonly used Time Stamp
Counter (TSC) timing source.
So, if you see messages like 'Losing too many ticks!' in
the kernel logs, and/or you are using
this on a notebook which does not
yet have an HPET, you should say "Y" here.
Symbol: X86_PM_TIMER
[=y]
Prompt: Power Management Timer
Support
Defined at
drivers/acpi/Kconfig:319
Depends on: !X86_VOYAGER && !X86_VISWS && !IA64_HP_SIM && (IA64 || X86) &&
X86 && ACPI && ACPI_
Location:
-> Power management options (ACPI,
APM) -> ACPI
(Advanced Configuration and Power Interface)
Support -> ACPI Support (ACPI [=y])
On Tue, 08 Mar 2005 03:06:24 +0100, Steinar H. Gunderson
<sgunderson@bigfoot.com> wrote:
> On Mon, Mar 07, 2005 at 09:02:38PM -0500, Tom Lane wrote:
>> One thought that was bothering me was that if the CPU goes idle while
>> waiting for disk I/O, its clock might stop or slow down dramatically.
>> If we believed such a counter for EXPLAIN, we'd severely understate
>> the cost of disk I/O.
>>
>> I dunno if that is the case on any Windows hardware or not, but none
>> of this thread is making me feel confident that we know what
>> QueryPerformanceCounter does measure.
>
> I believe the counter is actually good in such a situation -- I'm not a
> Win32
> guru, but I believe it is by far the best timer for measuring, well,
> performance of a process like this. After all, it's what it was designed
> to
> be :-)
>
> OBTW, I think I can name something like 15 or 20 different function
> calls to
> measure time in the Win32 API (all of them in use); it really is a giant
> mess.
>
> /* Steinar */
