seconds() function issue on Quad Core CPU

[Troy12]

Hello,

Actually, Quad Core PC still has issue related to Wait() function. So, changing Seconds() to Seconds(false) does not really fix all problems.

I was looking up on the web for any updates related to Intel processors, but couldn't find any yet.

Comments/Suggestions are appreciated.

Thanks!

[dug9000]

Did you look at the knowledge base articles in the solution post in this thread?:

http://forums.ni.com/ni/board/message?board.id=330&message.id=23221&requireLogin=False

Although it's not specifically related to quad cores, I suspect the cause is the same fundamental issue, some combination of the hardware, BIOS, and/or OS are not implementing QueryPerformanceCounter with a reliable mechanism. See Microsoft's knowledge base articles and the other posts in that thread for more information. In searching on MSDN, this issue has shown up many times in the past for many different reasons. This is not necessarily a CPU issue, it's potentially an issue with the BIOS or OS layer that decides what hardware timer to use for QueryPerformanceCounter.

Also, you might want to check with the manufacturer of your computer or motherboard for BIOS or other updates or drivers.

Hope this helps,

-Doug

Message Edited by dug9000 on 12-18-2009 07:51 PM

[dug9000]

In this kb: http://support.microsoft.com/kb/895980

The "more information" section contains the following explanation:

"By default, Windows Server 2003 Service Pack 2 (SP2) uses the PM timer for all multiprocessor APIC or ACPI HALs, unless the check process to determine whether the BIOS supports the APIC or ACPI HALs fails. If you are not running Windows Server 2003 SP2, you must force the AMD computer to use the PM timer by using the /usepmtimer switch.

Note The decision to use the PM timer or the TSC timer is made during a check that is performed at startup to query the BIOS and to determine whether the BIOS will support the PM timer functions. This check is not completely accurate on AMD chipsets. Therefore, you must use the /usepmtimer switch

In Windows Server 2003 SP2, this section of code was rewritten. Therefore, the correct performance monitor data appears on AMD chipsets that have Windows Server 2003 SP2 installed, and you do not have to use the /usepmtimer switch."

Also this one: http://support.microsoft.com/kb/938448/

Says the following in its more info section:

"Note If the BIOS does not support the APIC HAL or the ACPI HAL, contact the original equipment manufacturer to determine whether a BIOS update is available that will resolve the problem. If a BIOS update is not available, you must use the PM timer by using the /usepmtimer switch."

Also more details in this article:

http://blogs.msdn.com/oldnewthing/archive/2008/09/08/8931563.aspx

And this one:

http://blogs.msdn.com/oldnewthing/archive/2005/09/02/459952.aspx

It sounds like the issue can be caused by the BIOS, chipset, and/or OS not property detecting if the BIOS supports the PM timer rather than the TSC (I think TSC is affected by the clock speed of the CPU and is per CPU and thus isn't a reliable way to measure elapsed time for cpus that run at variable speed or for multiple cpu systems). Thus a BIOS or chipset driver update might help. I'm not completely sure though. All I know is what I've read from articles like these.

Also, the user with the issue for this forum post: http://forums.ni.com/ni/board/message?message.uid=862246#U862246

Was using an Intel T9400 cpu so this issue does not seem to be limited to AMD based systems.

If you decide to use the /usepmtimer switch, or find some other way to correct the issue, or discover more information that explains the issue better please let us know.

 

Hope this helps,

-Doug

Message Edited by dug9000 on 12-18-2009 09:12 PM

[Troy12]

Thanks for the information, Doug. Your comments/suggestions are appreciated.

I had read about the /usepmtimer option earlier and tried it out. It does fix the issue, but I am thinking of a way to have this fix available for deployment (target) machines wherein the pmtimer option is added only if there is an issue with the PC.

Another question that pops up is - in case, the boot.ini is changed on all computers regardless of # of cores, would it cause any issue?

I guess, this would have to be tried out on different computers!

[dug9000]

Glad the /usepmtimer flag worked. I'm not really sure if always using /usepmtimer is harmless or not. It sounds like it's a standard timer that the OS is expecting to be able to use, but I don't know for sure. You might want to contact support for Microsoft or the OEM of your computer and ask them. If you do find out any additional information, please let us know.

From the information in Microsoft's kb articles, it sounds like the fact that you have to use the flag indicates that there is a problem with the BIOS of the computer, so you might want to contact the manufacturer and bring the issue up with them.

If it's any consolation, I think this issue is pretty rare (though perhaps not as rare as it should be), so hopefully you won't have this problem on too many machines.

-Doug

[pwaszkewitz]

As an aside to the consideration of using a different API as a permanent workaround: QueryPerformanceCounter() is of course the highest resolution timer you can get and I am using it for tracing purposes when it is important to see the sequence and timing of events in fractions of milliseconds. For most purposes, however, I think that the millisecond resolution of GetSystemTime() is quite sufficient, and this API is, at least on my CoreDuo notebook, faster than QueryPerformanceCounter() by a factor of 10.

Regards

Peter