************************************************************* AMD http://lkml.org/lkml/2005/11/4/173 http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/26094.PDF http://developer.amd.com/article_print.jsp?id=92 (RH) [7] AMD's 7th generation processors return a CPUID base family value of '7'. These include AMD Athlon, AthlonXP, AthlonMP, and Duron. [8] AMD's 8th generation processors return an effective CPUID family of '0x0F'. These include AMD Opteron, Athlon64, and Turion. before 7th gen : ok 7th gen: P-state (performance state) change UP : warn about time inaccuracy SMP sol : disable powernow Use monotonic pseudo-TSC STPCLK-Throttling (temperature) : only done on UP, ok UP : warn about time inaccuracy 8th gen : P-state change UP : inaccuracy dual-core : locked-step ; inaccuracy SMP : may drift sol : disable powernow Use monotonic pseudo-TSC SMP, dual core : C1-clock ramping (halt) (power state : C-state) sol : idle=poll or disable C1-ramping Use monotonic pseudo-TSC STPCLK-Throttling (temperature) : single processor dual-core ok ; inaccuracy SMP : NOT ok (rare) Use monotonic pseudo-TSC Until TSC becomes invariant, AMD recommends that operating system developers avoid TSC as a fast timer source on affected systems. (AMD recommends that the operating system should favor these time sources in a prioritized manner: HPET first, then ACPI PM Timer, then PIT.) The following pseudo-code shows one way of determining when to use TSC: use_AMD_TSC() { // returns TRUE if ok to use TSC if (CPUID.base_family < 0xf) { // TSC drift doesn't exist on 7th Gen or less // However, OS still needs to consider effects // of P-state changes on TSC return TRUE; } else if (CPUID.AdvPowerMgmtInfo.TscInvariant) { // Invariant TSC on 8th Gen or newer, use it // (assume all cores have invariant TSC) return TRUE; } else if ((number_processors == 1)&&(number_cores == 1)){ // OK to use TSC on uni-processor-uni-core // However, OS still needs to consider effects // of P-state changes on TSC return TRUE; } else if ( (number_processors == 1) && (CPUID.effective_family == 0x0f) && !C1_ramp_8gen ){ // Use TSC on 8th Gen uni-proc with C1_ramp off // However, OS still needs to consider effects // of P-state changes on TSC return TRUE; } else { return FALSE; } } C1_ramp_8gen() { // Check if C1-Clock ramping enabled in PMM7.CpuLowPwrEnh // On 8th-Generation cores only. Assume BIOS has setup // all Northbridges equivalently. return (1 & read_pci_byte(bus=0,dev=0x18,fcn=3,offset=0x87)); } When an operating system can not avoid using TSC in the short-term, the operating system will need to either re-synchronize the TSC of the halted core when exiting halt or disable C1-clock ramping. The pseudo-code for disabling C1-clock ramping follows: if ( !use_AMD_TSC() && (CPUID.effective_family == 0x0f) && C1_ramp_8gen() ){ for (i=0; i < number_processors; ++i){ // Do for all NorthBridges in platform tmp = read_pci_byte(bus=0,dev=0x18+i,fcn=3,offset=0x87); tmp &= 0xFC; // clears pmm7[1:0] write_pci_byte(bus=0,dev=0x18+i,fcn=3,offset=0x87,tmp) } } Future TSC Directions and Solutions =================================== Future AMD processors will provide a TSC that is P-state and C-State invariant and unaffected by STPCLK-throttling. This will make the TSC immune to drift. Because using the TSC for fast timer APIs is a desirable feature that helps performance, AMD has defined a CPUID feature bit that software can test to determine if the TSC is invariant. Issuing a CPUID instruction with an %eax register value of 0x8000_0007, on a processor whose base family is 0xF, returns "Advanced Power Management Information" in the %eax, %ebx, %ecx, and %edx registers. Bit 8 of the return %edx is the "TscInvariant" feature flag which is set when TSC is P-state, C-state, and STPCLK-throttling invariant; it is clear otherwise. The rate of the invariant TSC is implementation-dependent and will likely *not* be the frequency of the processor core; however, its period should be short enough such that it is not possible for two back-to-back rdtsc instructions to return the same value. Software which is trying to measure actual processor frequency or cycle-performance should use Performance Event 76h, CPU Clocks not Halted, rather than the TSC to count CPU cycles. ************************************************************* Intel Pentium M family [06H], models [09H, 0DH] UP warn about time inaccuracy SMP SOL : disable speedstep Pentium 4 processors, Intel Xeon family [0FH], models [00H, 01H, or 02H] UP warn about time inaccuracy SMP SOL : disable speedstep Other : ok http://download.intel.com/design/Xeon/specupdt/30675712.pdf http://forum.rightmark.org/post.cgi?id=print:6:269&user=%20Dmitri%20Besedin&color=1 http://bochs.sourceforge.net/techspec/24161821.pdf cpuid cpuz AFAIK this problem only concerns Prescott CPUs, but I bet future production will also use the same rule. Well, from what Intel states in one of their docs (Intel(R) Pentium(R) M Processor on 90 nm Process with 2-MB L2 Cache, Specification Update, Document No. 302209-010 (http://www.intel.com/design/mobile/specupdt/302209.htm) ), your supposition is true: Article V. For Pentium M processors (family [06H], models [09H, 0DH]); for Pentium 4 processors, Intel Xeon processors (family [0FH], models [00H, 01H, or 02H]); and for P6 family processors: the timestamp counter increments with every internal processor clock cycle. The internal processor clock cycle is determined by the current core-clock to bus-clock ratio. Intel(R) SpeedStep(R) technology transitions may also impact the processor clock. Article VI. For Pentium 4 processors, Intel Xeon processors (family [0FH], models [03H and higher]): the time-stamp counter increments at a constant rate. That rate may be set by the maximum core-clock to bus-clock ratio of the processor or may be set by the frequency at which the processor is booted. The specific processor configuration determines the behavior. Constant TSC behavior ensures that the duration of each clock tick is uniform and supports the use of the TSC as a wall clock timer even if the processor core changes frequency. This is the architectural behavior moving forward. It's a pity they call this sucking TSC behavior an "architectural behavior moving forward" ************************************************************* HPET http://www.intel.com/hardwaredesign/hpetspec_1.pdf