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 <[EMAIL PROTECTED]> 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 */
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
