5 ms·

For those unaware, The TSC is an on-die timer on modern x86 processors which brings lower latencies than accessing the HPET, which is located on the chipset. TS

For those unaware, The TSC is an on-die timer on modern x86 processors which brings lower latencies than accessing the HPET, which is located on the chipset. TSC on the other hand is also an instruction (RDTSC) and can be used simultaneously by both the kernel and in user application code, if permitted. TSC had some problems historically with SMP and for a time HPET was pretty much the only high resolution timer available, but nowadays modern CPUs from both Intel/AMD support invariant TSC or constant TSC, which if supported, will be preferred by operating systems. This was a good article explaining their findings, but it missed the industry shift back toward favouring TSC.

wtallis 8y ago
Is there clear documentation from either CPU vendor about how "invariant" TSC is when overclocking the processor? It's certainly plausible that it still accurately reflects wall time given that they've gone through the trouble of creating a clock that is unaffected by normal CPU power management adjusting core frequencies, but the TSC frequency may still be derived from a source that's affected by some overclocking methods.
- notaplumber 8y ago
  I'm not sure of the methods, but it's documented that invariant TSC is constant. Operating systems depend on that if the CPUID feature bit is set. https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf https://software.intel.com/sites/default/files/managed/39/c5... (24MB mobile warning): "17.17.1 Invariant TSC" "The invariant TSC will run at a constant rate in all ACPI P-, C-, and T-states. This is an architectural behavior moving forward. On processors with invariant TSC support, the OS may use the TSC for wall clock timer services (instead of ACPI or HPET timers). TSC reads are much more efficient and do not incur the overhead associated with a ring transition [system call, u<=>k context switch] or access to a platform resource. [Device I/O]" If overclockers methods are breaking this promise, then operating systems have very little recourse. I suspect they are not, however. The point is that the TSC is not derived from the CPU clock.
  - wtallis 8y ago
    > If overclockers methods are breaking this promise, then operating systems have very little recourse. I guess the real concern is where does software get its information about the ratio of the TSC's rate to the progression of actual wall time. If it's derived from a constant multiplier of the CPU base clock or something like that, then adjusting the base clock could be quite problematic for benchmarking even if that base clock speed remains constant throughout a benchmark run. On the other hand, if the TSC to wall time ratio is measured using an external clock (like HPET), then most overclocking situations are probably fine (since it's pretty rare to overclock peripheral busses on modern platforms). And since RDTSC is quite deliberately an unprivileged instruction, it's not just the OS we have to worry about on the software side. But hopefully most application authors that directly use the TSC instead of portable APIs know what they're doing. (I wouldn't bet on it.)
    - notaplumber 8y ago
      The TSC is periodically recalibrated by operating systems from the some other available timer, like HPET or ACPI PM timer.
  - dragontamer 8y ago
    Extreme overclockers on Intel platforms DO change the BCLK, which from my understanding, changes the TSC timing. https://www.tweaktown.com/guides/7481/tweaktowns-ultimate-intel-skylake-overclocking-guide/index3.html https://www.tweaktown.com/guides/7481/tweaktowns-ultimate-in... Its not a "common" practice, but its certainly an overclocking practice that enough overclockers do that its a concern.
dragontamer 8y ago
I'm not sure if AMD properly supports invariant TSC. See this post from Agner Fog with regards to the Zen cores: http://www.agner.org/optimize/blog/read.php?i=838 http://www.agner.org/optimize/blog/read.php?i=838 > The varying clock frequency was a big problem for my performance tests because it was impossible to get precise and reproducible measurements of computation times. It helps to warm up the processor with a long sequence of dummy calculations, but the clock counts were still somewhat inaccurate. The Time Stamp Counter (TSC), which is used for measuring the execution time of small pieces of code, is counting at the nominal frequency. The Ryzen processor has another counter called Actual Performance Frequency Clock Counter (APERF) which is similar to the Core Clock Counter in Intel processors. Unfortunately, the APERF counter can only be read in kernel mode, unlike the TSC which is accessible to the test program running in user mode. I had to calculate the actual clock counts in the following way: The TSC and APERF counters are both read in a device driver immediately before and after a run of the test sequence. The ratio between the TSC count and the APERF count obtained in this way is then used as a correction factor which is applied to all TSC counts obtained during the running of the test sequence. This method is awkward, but the results appear to be quite precise, except in the cases where the frequency is varying considerably during the test sequence. My test program is available at www.agner.org/optimize/#testp --------------- EDIT: Odd. AMD Documentation of 17h (aka Zen) suggests that the TSC is invariant: https://support.amd.com/TechDocs/54945_PPR_Family_17h_Models_00h-0Fh.pdf https://support.amd.com/TechDocs/54945_PPR_Family_17h_Models... See bottom of page 82. I can't say I've run tests as thoroughly as Agner Fog has done however, or even have access to Zen cores.
- notaplumber 8y ago
  AMD certainly proclaims to support it on the pre-Ryzen hardware I have, if the bit is set than software no reason not to trust it. But it should really be no surprise that CPU errata sheets are not small.
- wtallis 8y ago
  I think that's saying that TSC is invariant with respect to wall time, but what Agner Fog wants is a counter that's invariant with respect to actual CPU clock cycles, so that he can count how many cycles an instruction takes even if the clock speed of the CPU changes during a test run.

wtallis 8y ago

Is there clear documentation from either CPU vendor about how "invariant" TSC is when overclocking the processor? It's certainly plausible that it still accurately reflects wall time given that they've gone through the trouble of creating a clock that is unaffected by normal CPU power management adjusting core frequencies, but the TSC frequency may still be derived from a source that's affected by some overclocking methods.

notaplumber 8y ago
I'm not sure of the methods, but it's documented that invariant TSC is constant. Operating systems depend on that if the CPUID feature bit is set. https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf https://software.intel.com/sites/default/files/managed/39/c5... (24MB mobile warning): "17.17.1 Invariant TSC" "The invariant TSC will run at a constant rate in all ACPI P-, C-, and T-states. This is an architectural behavior moving forward. On processors with invariant TSC support, the OS may use the TSC for wall clock timer services (instead of ACPI or HPET timers). TSC reads are much more efficient and do not incur the overhead associated with a ring transition [system call, u<=>k context switch] or access to a platform resource. [Device I/O]" If overclockers methods are breaking this promise, then operating systems have very little recourse. I suspect they are not, however. The point is that the TSC is not derived from the CPU clock.
- wtallis 8y ago
  > If overclockers methods are breaking this promise, then operating systems have very little recourse. I guess the real concern is where does software get its information about the ratio of the TSC's rate to the progression of actual wall time. If it's derived from a constant multiplier of the CPU base clock or something like that, then adjusting the base clock could be quite problematic for benchmarking even if that base clock speed remains constant throughout a benchmark run. On the other hand, if the TSC to wall time ratio is measured using an external clock (like HPET), then most overclocking situations are probably fine (since it's pretty rare to overclock peripheral busses on modern platforms). And since RDTSC is quite deliberately an unprivileged instruction, it's not just the OS we have to worry about on the software side. But hopefully most application authors that directly use the TSC instead of portable APIs know what they're doing. (I wouldn't bet on it.)
  - notaplumber 8y ago
    The TSC is periodically recalibrated by operating systems from the some other available timer, like HPET or ACPI PM timer.
- dragontamer 8y ago
  Extreme overclockers on Intel platforms DO change the BCLK, which from my understanding, changes the TSC timing. https://www.tweaktown.com/guides/7481/tweaktowns-ultimate-intel-skylake-overclocking-guide/index3.html https://www.tweaktown.com/guides/7481/tweaktowns-ultimate-in... Its not a "common" practice, but its certainly an overclocking practice that enough overclockers do that its a concern.

dragontamer 8y ago

I'm not sure if AMD properly supports invariant TSC. See this post from Agner Fog with regards to the Zen cores: http://www.agner.org/optimize/blog/read.php?i=838 http://www.agner.org/optimize/blog/read.php?i=838 > The varying clock frequency was a big problem for my performance tests because it was impossible to get precise and reproducible measurements of computation times. It helps to warm up the processor with a long sequence of dummy calculations, but the clock counts were still somewhat inaccurate. The Time Stamp Counter (TSC), which is used for measuring the execution time of small pieces of code, is counting at the nominal frequency. The Ryzen processor has another counter called Actual Performance Frequency Clock Counter (APERF) which is similar to the Core Clock Counter in Intel processors. Unfortunately, the APERF counter can only be read in kernel mode, unlike the TSC which is accessible to the test program running in user mode. I had to calculate the actual clock counts in the following way: The TSC and APERF counters are both read in a device driver immediately before and after a run of the test sequence. The ratio between the TSC count and the APERF count obtained in this way is then used as a correction factor which is applied to all TSC counts obtained during the running of the test sequence. This method is awkward, but the results appear to be quite precise, except in the cases where the frequency is varying considerably during the test sequence. My test program is available at www.agner.org/optimize/#testp --------------- EDIT: Odd. AMD Documentation of 17h (aka Zen) suggests that the TSC is invariant: https://support.amd.com/TechDocs/54945_PPR_Family_17h_Models_00h-0Fh.pdf https://support.amd.com/TechDocs/54945_PPR_Family_17h_Models... See bottom of page 82. I can't say I've run tests as thoroughly as Agner Fog has done however, or even have access to Zen cores.

notaplumber 8y ago
AMD certainly proclaims to support it on the pre-Ryzen hardware I have, if the bit is set than software no reason not to trust it. But it should really be no surprise that CPU errata sheets are not small.
wtallis 8y ago
I think that's saying that TSC is invariant with respect to wall time, but what Agner Fog wants is a counter that's invariant with respect to actual CPU clock cycles, so that he can count how many cycles an instruction takes even if the clock speed of the CPU changes during a test run.