Explanation for the USEPMTIMER switch in the boot.ini
Hello All,
This post covers the use of the USEPMTIMER switch in the boot.ini and also shows how it affects the operating system
Symptoms
Dual Core or multiprocessor AMD Opteron processors may encounter Time Stamp Counter (TSC) drift in certain conditions. Whether the system is affected by this issue depends on the specific ProLiant server generation, the number and type of AMD Opteron processors installed, the operating system, and whether AMD’s PowerNow! feature is being utilized. This condition affects operations such as network communications and performance monitoring tasks that are sensitive to system time. For example, Microsoft Active Directory domain controllers can report an Unexpected Network Error (Event ID 1054).
Event Description:
Windows cannot obtain the domain controller name for your computer network. (An unexpected network error occurred ) . Group Policy processing aborted.
In addition, a negative PING time may be returned after issuing the PING command. The negative PING time occurs because of a Time Stamp Counter drift occurring on AMD Opteron platforms which include more than one processor core.
You may also see that the performance monitor shows you wrong values.
Cause
Many operating systems use the TSC as a timekeeping source. Each processor core (whether it is a single-core processor or dual-core processor) includes a TSC. When the TSC for different processor cores are not synchronized, the above symptoms and behaviors can occur if the operating system is using the TSC as a timekeeping source
Resolution
Edit the BOOT.ini file and add the parameter "/usepmtimer", then reboot the server. Adding the "/usepmtimer" parameter to the BOOT.INI file configures the Windows operating system to use the PM_TIMER, rather than the Time Stamp Counter.
Note: When installing the latest AMD PowerNow! Technology driver from AMD, the BOOT.INI file will automatically be updated with the “/usepmtimer” parameter. While the driver itself does not resolve this issue, the installation process will make the necessary changes to the BOOT.INI file to prevent the issue from occurring.
Detailed Explanation:-
A Microsoft Windows Server 2003-based server may experience time-stamp counter drift if the server uses dual-core AMD Opteron processors or multiprocessor AMD Opteron processors. When this problem occurs, operations that rely on the time-stamp counter may not function correctly. These operations include network communications and performance monitoring. This problem occurs when the time-stamp counters for different processor cores are not synchronized. Windows Server 2003 uses the time-stamp counter as a timekeeping source. Each processor contains a time-stamp counter. Basically, configuring the /USEPMTIMER switch forces the machine to select the ACPI clock for the performance counter timer instead of using the time stamp counter (TSC). Note that only ACPI HALs ever use the PM timer for the function QueryPerformanceCounter; APM and other non-ACPI HALs use the TSC.
W2K SP4:
- The PIC ACPI and Uniprocessor (UP) APIC ACPI HALs use the PM timer for QueryPerformanceCounter.
XP SP2:
- The PIC ACPI and UP APIC ACPI HALs use the PM timer for QueryPerformanceCounter.
- The multiprocessor (MP) APIC ACPI HAL does not use the PM timer for QueryPerformanceCounter by default, instead using the TSC. This can be overridden in three ways. First, the /USEPMTIMER switch may be specified in boot.ini. Second, a mask including 0x10 can be written to HKLM\System\CurrentControlSet\Control\HAL\14140000FFFFFFFF to set a special HAL hack flag (not recommended). Third, the USE_PLATFORM_CLOCK bit can be set in the FADT presented by the system BIOS (bios-level from the hardware vendor).
W2K3 SP1:
- The PIC ACPI and UP APIC ACPI HALs use the PM timer for QueryPerformanceCounter.
- The MP APIC ACPI HAL does not use the PM timer for QueryPerformanceCounter by default, instead using the TSC. This can be overridden in two ways. First, the /USEPMTIMER switch may be specified in boot.ini. Second, the USE_PLATFORM_CLOCK bit can be set in the FADT presented by the system BIOS (note W2K3 does not read the registry value, as XP does - using the registry to set this is of course not recommended).
- W2K3 SP2 uses the PM timer by default for all APIC ACPI HALs, unless the check to see if the BIOS supports this fails .
Unless you are running SP2 for W2K3 (where we use the PM timer for MP APIC ACPI HALs by default now), you must force the use of the PM timer on AMD machines via the /USEPMTIMER switch. The decision to use the PM timer versus the TSC is actually a check done on boot to query the BIOS, and determine whether or not it will properly support the PM timer functions - this check is not 100% accurate on AMD chipsets, and that is why forcing /USEPMTIMER is required. This section of code was rewritten for W2K3 SP2, and you should see the proper performance monitor data on AMD chipsets with SP2 installed without the use of the /USEPMTIMER switch.
The switch /usepmtimer will prevent a lot of known issues with several AMD CPU´S, the solution is to add that switch in the boot.ini or to apply the AMD drivers that will put this switch on the boot.ini
The AMD multiprocessor driver requires this setting for things to work properly, because the default processor time stamp counter (TSC) is not synchronized properly between cores on chipsets for AMD multiprocessor boards. Using the switch forces the system to use the PM timer instead of the TSC timer, which resolves the issue.
Additional Information:-
Platforms Affected
• HP ProLiant BL465c Server series
• HP ProLiant BL685c Server series
• HP ProLiant DL145 G2 Server series
• HP ProLiant DL145 G3 Server series
• HP ProLiant DL145 Server series
• HP ProLiant DL365 Server series
• HP ProLiant DL385 G2 Server series
• HP ProLiant DL385 Packaged Cluster with MSA500G2
• HP ProLiant DL385 Server series
• HP ProLiant DL585 G2 Server series
• HP ProLiant DL585 G2 Storage Server
• HP ProLiant DL585 Server series
• HP ProLiant DL585 Storage Server
• HP ProLiant ML115 Server series
Operating Systems Affected
• Microsoft Windows Server 2003 Enterprise Edition
• Microsoft Windows Server 2003 Enterprise x64
• Microsoft Windows Server 2003 R2 Enterprise Edition
• Microsoft Windows Server 2003 R2 Standard Edition
• Microsoft Windows Server 2003 R2 Standard x64 Edition
• Microsoft Windows Server 2003 Standard Edition
• Microsoft Windows Server 2003 Standard x64
• Microsoft Windows Server 2003 Web Edition
Note: This condition is not specific to HP ProLiant servers and can occur on servers from other manufacturers.
Newer operating systems typically do not use the TSC by default if other timers are available in the system which can be used as a timekeeping source. Other available timers include the PM_Timer and the High Precision Event Timer (HPET). All HP ProLiant servers include the PM_Timer, and the latest generation of HP ProLiant servers supporting AMD Opteron 2200-series and 8200-series processors support HPET. These timers are not affected by this condition. New operating system Windows Server 2008 is not affected by this issue.
Some applications, such as SAP, require a precise clock to time stamp various events. Each processor has an individual internal clock that increments a Time Stamp Counter (TSC) which is available to any application and runs asynchronous from the TSCs in the other processors. Consequently a database application like SAP could query a TSC in one processor for a time stamp and get one answer. Subsequently the software OS scheduler could move that task to another processor and queries to that processor's TSC could result in time stamp information that is completely out of synch with the former query to the other processor.
The document from AMD in the below link also explains the above problem
https://developer.amd.com/Assets/TSC_Dual-Core_Utility.pdf
https://developer.amd.com/Pages/1214200692.aspx
Comments
Anonymous
January 01, 2003
PingBack from http://lostdriveblog.com/2008/02/18/explanation-for-the-usepmtimer-switch-in-the-bootini/Anonymous
July 10, 2008
In our environment, we saw the issue in Windows server 2003 x64 enterprise edition. I'm assuming that the BIOS check failed. Also, how do I find if we use APIC ACPI HALs?Anonymous
March 17, 2010
we see this problem on Amazon cloud with Windows 2008... can it be cause by any other hardware/software issue?