9 ms·
A Timely Discovery: Examining Our AMD 2nd Gen Ryzen Results
- ComputerGuru 9y agoReally, the article should be titled “Intel CPU suffer performance hit with HPET bug”
- wtallis 9y agoIt's not clear to me whether there's an actual HPET bug, or if is just that Intel's HPET is another victim of the Meltdown bug and the damage caused by workarounds for Meltdown.
- dogma1138 9y agoThere is no actual performance hit the number of frames per a given unit of real time is still identical the only thing that happens is that the frame counter on the machine does not count it accurately.
- wtallis 9y agoThat may be true for some applications, but in general the FPS meter isn't the only thing that cares about wall time.
- dogma1138 9y agoYes but were talking about this specific use case I'm not entirely sure if this actually would affect more significant things HPET was always PITA. I am wondering where did they get the Intel uses 24mhz timer from tho... hpet0: 4 comparators, 64-bit 14.318180 MHz counter
- yardsale 8y agoThat's not true at all. HPET is very reliable and not prone to skewing at all. The problem is that accessing an HPET timestamp (via QPC in Windows) is very slow on certain Intel and AMD platforms. The HPET bug was already discovered last July, so Meltdown and Spectre have nothing to do with the bug but maybe adding performance penalties on top. Read this for details and try the timer benchmark in there: https://www.overclockers.at/articles/the-hpet-bug-what-it-is-and-what-it-isnt https://www.overclockers.at/articles/the-hpet-bug-what-it-is...
- dman 9y agoThat would not have made it past Intels marketing department.
- wtallis 9y agoIntel's marketing department doesn't know the titles until the article is published.
- ysleepy 9y agoSummary: HPET Timer has a significant performance impact, especially on intel. Anandtech turned them to non-default forced-on and now has lots of results which cant be compared to other benchmarkers. I'm interested in first-generation Ryzen numbers. Especially considering AMD explicitly advised turning HPET off while anandtech turned them on.
- notaplumber 9y agoFor 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 9y agoIs 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 9y agoI'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.
- 9y ago
- brianolson 9y agoSo, this is all about HPET _as it is used by Windows_, right? They talk about 'forced on in the OS', they mean Windows. Anyone know how the various PC timers are used in Linux?
- paol 9y agoI think Linux will use HPET if the hardware makes it available. You can prevent that with "hpet=disable" in the kernel boot parameters.
- cesarb 9y agoYes, Linux will use the HPET if it's available, but it prefers the TSC when possible, which is the case in most modern CPUs. For instance, you will see the following in the kernel log: [ 0.062020] clocksource: Switched to clocksource hpet [...] [ 2.383237] clocksource: Switched to clocksource tsc Here, it started with the HPET, calibrated the TSC, and switched to it. There's no need to disable the HPET for it to chose something else as the best timing source.
- floatboth 9y agoAny reasonable OS should use TSC as the main timer. e.g. FreeBSD assigns a higher quality score to TSC: Timecounter "TSC-low" frequency 1500043470 Hz quality 1000 Timecounter "i8254" frequency 1193182 Hz quality 0 Timecounter "HPET" frequency 14318180 Hz quality 950 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
- amluto 9y ago> Instead of being a benefit to testing, what our investigation found is that when HPET is forced as the sole system timer, it can sometimes a hindrance to system performance, particularly gaming performance. That doesn’t surprise me at all. The HPET is awful. Reading it takes thousands of cycles. Reading it concurrently on multiple cores is even worse. Even using it as a timer (to fire an interrupt at a given time) is highly dubious — IIRC it only supports “interrupt of time == X” and not “interrupt the first time that time >= X”, which means that setting a timer without races requires manually checking that the timeout hasn’t already expired after programming the timer, which is extra bad given how incredibly slow the HPET is. (I maintain the Linux vDSO, and the HPET has so many problems that I disabled vDSO HPET support entirely a while back.)
- cesarb 9y ago> (I maintain the Linux vDSO, and the HPET has so many problems that I disabled vDSO HPET support entirely a while back.) For those who don't know: the vDSO is a "dynamic library" provided by the Linux kernel to every process. System calls in modern Linux are made by calling a function exported by the vDSO, which then does the real system call, using the fastest method available. There are a few special cases in the vDSO for time-related system calls: depending on the currently active clock source, it can do a few calculations and return, without having to actually do a system call. This makes getting the current time much faster.
- josteink 9y agoWe were wrong. This is how we were wrong. This is how we’re going to avoid the same mistake in the future. We’re retracting our results and will publish updated results when ready. Clear and simple. I wish more media could be so straight forward and honest as this.
- headsoup 9y agoWhat I don't understand is that AMD/Intel differ so much. The subsequent question I haven't seen clarified is: In any of these situations, are Intel's results actually accurate FPS or could it be showing 'accelerated' FPS? I.e. is Intel taking a performance hit, or are their 'non-HPET' numbers cosmetically showing faster performance that isn't there?
- wtallis 9y ago> What I don't understand is that AMD/Intel differ so much. At least one of the factors seems to be the Meltdown workarounds that are required on Intel but not AMD processors. My intuition is that this explanation is sufficient to account for the entire discrepancy between vendors, but I can't rule out other factors. (Querying the HPET incurs all the Meltdown workaround overhead of accessing peripherals like storage, but with none of the actual waiting on a peripheral device, so on a percentage basis this is probably the most severely affected task.) > I.e. is Intel taking a performance hit, or are their 'non-HPET' numbers cosmetically showing faster performance that isn't there? When the system is forced to always use the HPET instead of the TSC, the performance hit is real and not just an artifact of inaccurate timers. When you're not overclocking, the TSC is usually reliable and TSC-based time measurements should differ from HPET-based time measurements only by the overhead of accessing the HPET. That overhead got much larger this year for Intel processors. Ian's initial benchmarks didn't include overclocked processors, just a test configuration intended to be suitable for future comparison against overclocked processors.
- headsoup 8y agoThanks for the explanation