3 ms·

How quickly do CPUs change clock speeds?

62 points by zdw 4y ago

LarsAlereon 4y ago
It's interesting how the HP OEM system didn't have SpeedShift working, which is absolutely critical to system responsiveness. I would like to see if OEMs have this sorted out on modern systems or if there's still brand-to-brand variation. Semi-related, but there can be a surprising amount of performance variation between motherboards that can be difficult to benchmark. DPC latency can vary between <50us to ~250us board-to-board: https://www.anandtech.com/show/16973/the-asrock-x570s-pg-riptide-motherboard-review/5 https://www.anandtech.com/show/16973/the-asrock-x570s-pg-rip...
johntb86 4y ago
> Sadly, Qualcomm was very bad at implementing caches, but that’s a story for another day. Anyone know what that story is?
- clamchowder 4y ago
  Big cores each have a 512 KB L2 cache with a latency of around 24 cycles, while the little ones each have a 256 KB L2 with ~23 cycle latency. It's really terrible considering the low 2.34/1.6 GHz clock speeds. Then there's no multi-megabyte last level cache, so it's going out to memory a lot. They do have 3 cycle L1D latency, but again that's at low clocks, and it's a 24 KB L1D so it's 25% smaller than most L1Ds we see today. Not great considering you're eating 20+ cycle L2 latency once you miss the L1D, unlike most CPUs today that have 12 cycle latency for 256 or 512 KB L2s.
theevilsharpie 4y ago
This article isn't accurate, in the sense that it's actually measuring how long the operating system takes to reach the CPU's maximum clock speed, rather than how long it physically takes the CPU to reach that speed. Modern processors can switch frequencies very fast -- generally within microseconds. An example from the machine I'm currently using: $ grep 'model name' /proc/cpuinfo | uniq; sudo cpupower frequency-info -y -m model name : Intel(R) Core(TM) i5-4310U CPU @ 2.00GHz analyzing CPU 0: maximum transition latency: 20.0 us Even very deep CPU idle states can be exited in <1 ms. With respect to the operating system, the amount of time it takes to reach maximum frequency from idle depends on: - How frequently the OS checks to see if the frequency should be increased - Whether the OS will step through increasing frequencies, or go straight to the max frequency - If the OS is stepping through increasing frequencies, how many it needs to step through - Whether the core is already active, or if it needs to be awakened from a sleep state first It looks like the OP is using Windows. Windows has a number of hidden (and poorly documented) tunables that control the above settings, and would have a significant impact on how quickly a CPU can reach max frequency. Microsoft used to have an extensive document (specifically, a Word document for Windows Server 2008) describing how to tune these parameters using the `powercfg` CLI tool and provided a detailed reference for each parameter, which I unfortunately can't find anymore. It looks like Microsoft's modern server performance tuning documentation describes a subset of these parameters.[1] Linux has similar tunables for its `ondemand` CPU scheduler.[2] It looks like the default sampling rate to determine whether to adjust the frequency is 1000 times greater than the transition latency, or about 20 milliseconds on my machine. I'm not familiar with macOS, but it likely has something similar (although it may not be user-accessible). [1] https://docs.microsoft.com/en-us/windows-server/administration/performance-tuning/hardware/power/power-performance-tuning https://docs.microsoft.com/en-us/windows-server/administrati... [2] https://www.kernel.org/doc/html/v5.15/admin-guide/pm/cpufreq.html https://www.kernel.org/doc/html/v5.15/admin-guide/pm/cpufreq...
- vardump 4y ago
  When a comment has the insight you expected from the article. Thanks!
- clamchowder 4y ago
  Hey, author here. The Snapdragon 670, Snapdragon 821, and i5-6600K tests were done on Linux, and the rest were done on Windows. If Windows is delaying boost, it doesn't seem to be any different from Linux. And lack of intermediate states between lowest clock and max clock on all three of those (not considering the little cores) indicates the OS is not stepping through frequencies. Since people don't usually write their own OS, I don't think it's correct to take the "maximum transition latency" reported by the CPU to mean anything, because users will never observe that transition speed. Also, processors that rely on the OS (no "Speed Shift") can transition very fast if their voltages are held high to start with, suggesting most of the latency comes from waiting for voltages to increase. Please also read about Intel's "Speed Shift". While it's fairly new (only debuted in 2015), it means the CPU can clock up by itself without waiting for a transition command from the OS.
  - theevilsharpie 4y ago
    > Since people don't usually write their own OS, I don't think it's correct to take the "maximum transition latency" reported by the CPU to mean anything, because users will never observe that transition speed. The Linux CPU frequency governor literally uses it as part of the algorithm for calculating its sampling rate (i.e., how frequently it checks whether to adjust the processor's frequency). > Please also read about Intel's "Speed Shift". While it's fairly new (only debuted in 2015), it means the CPU can clock up by itself without waiting for a transition command from the OS. Hardware-managed P-states don't need to wait for the OS to send a command to change the frequency, but the processor still performs periodic sampling to determine what the frequency should be (this happens ever millisecond on modern AMD and Intel hardware), the processor isn't necessarily going to choose the maximum frequency right away, and it's still subject to delays from the OS (e.g., Windows core parking). In any case, a multi-millisecond delay in switching frequency isn't because the processor is waiting for the voltage to increase.
grapescheesee 4y ago
I think it's great the author made an account today on HN, and is replying to questions from his post. This is one if the best parts of the community here. I would love to see some test done on newer CPUs, and also if any BIOS tweaks can be used to dramatically cut the time frame. It could also be interesting if you logged the PSU from the wall or the AC to DC adapter as a metric. It wouldn't be that comparable system to system. Yet it might show more linear draw vs exponential.
- clamchowder 4y ago
  > I think it's great the author made an account today on HN, and is replying to questions from his post. This is one if the best parts of the community here. :) > I would love to see some test done on newer CPUs So, the site is a free time thing run by several people, all of which are either students or have other full time jobs (not full time reviewers with samples of the latest hardware). No one happened to have an ICL/TGL/ADL CPU available. I do have an ADL result from earlier today showing full boost after 0.5 ms, but that person also overclocked and may have used a static voltage. Maybe we can get an addenum out with more results but I wouldn't bet on it. And yeah probably. In an extreme scenario you could just lock the CPU to its highest clock. Then you'll never see a transition period at all. > logged the PSU I don't have a power meter or PSU capable of logging
  - jeffbee 4y ago
    Big fan of your site. Travis Downs has done some work on characterizing hardware transition latency. I believe his tools are on GitHub. https://travisdowns.github.io/blog/2020/01/17/avxfreq1.html https://travisdowns.github.io/blog/2020/01/17/avxfreq1.html
    - clamchowder 4y ago
      Yeah, he has some pretty interesting stuff. But AVX512 transition latency is pretty different from clocking up from idle. The CPU is already running at full tilt, and is making a relatively small frequency/voltage change. You can see from his writeup that it's well under a millisecond. I believe newer Intel CPUs have done away with AVX-512 downclocking completely. I probably won't be able to look into that specific issue since I don't have any AVX-512 capable CPUs.

62 points by zdw 4y ago

It's interesting how the HP OEM system didn't have SpeedShift working, which is absolutely critical to system responsiveness. I would like to see if OEMs have this sorted out on modern systems or if there's still brand-to-brand variation. Semi-related, but there can be a surprising amount of performance variation between motherboards that can be difficult to benchmark. DPC latency can vary between <50us to ~250us board-to-board: https://www.anandtech.com/show/16973/the-asrock-x570s-pg-riptide-motherboard-review/5 https://www.anandtech.com/show/16973/the-asrock-x570s-pg-rip...

johntb86 4y ago

> Sadly, Qualcomm was very bad at implementing caches, but that’s a story for another day. Anyone know what that story is?

clamchowder 4y ago
Big cores each have a 512 KB L2 cache with a latency of around 24 cycles, while the little ones each have a 256 KB L2 with ~23 cycle latency. It's really terrible considering the low 2.34/1.6 GHz clock speeds. Then there's no multi-megabyte last level cache, so it's going out to memory a lot. They do have 3 cycle L1D latency, but again that's at low clocks, and it's a 24 KB L1D so it's 25% smaller than most L1Ds we see today. Not great considering you're eating 20+ cycle L2 latency once you miss the L1D, unlike most CPUs today that have 12 cycle latency for 256 or 512 KB L2s.

theevilsharpie 4y ago

This article isn't accurate, in the sense that it's actually measuring how long the operating system takes to reach the CPU's maximum clock speed, rather than how long it physically takes the CPU to reach that speed. Modern processors can switch frequencies very fast -- generally within microseconds. An example from the machine I'm currently using: $ grep 'model name' /proc/cpuinfo | uniq; sudo cpupower frequency-info -y -m model name : Intel(R) Core(TM) i5-4310U CPU @ 2.00GHz analyzing CPU 0: maximum transition latency: 20.0 us Even very deep CPU idle states can be exited in <1 ms. With respect to the operating system, the amount of time it takes to reach maximum frequency from idle depends on: - How frequently the OS checks to see if the frequency should be increased - Whether the OS will step through increasing frequencies, or go straight to the max frequency - If the OS is stepping through increasing frequencies, how many it needs to step through - Whether the core is already active, or if it needs to be awakened from a sleep state first It looks like the OP is using Windows. Windows has a number of hidden (and poorly documented) tunables that control the above settings, and would have a significant impact on how quickly a CPU can reach max frequency. Microsoft used to have an extensive document (specifically, a Word document for Windows Server 2008) describing how to tune these parameters using the `powercfg` CLI tool and provided a detailed reference for each parameter, which I unfortunately can't find anymore. It looks like Microsoft's modern server performance tuning documentation describes a subset of these parameters.[1] Linux has similar tunables for its `ondemand` CPU scheduler.[2] It looks like the default sampling rate to determine whether to adjust the frequency is 1000 times greater than the transition latency, or about 20 milliseconds on my machine. I'm not familiar with macOS, but it likely has something similar (although it may not be user-accessible). [1] https://docs.microsoft.com/en-us/windows-server/administration/performance-tuning/hardware/power/power-performance-tuning https://docs.microsoft.com/en-us/windows-server/administrati... [2] https://www.kernel.org/doc/html/v5.15/admin-guide/pm/cpufreq.html https://www.kernel.org/doc/html/v5.15/admin-guide/pm/cpufreq...

vardump 4y ago
When a comment has the insight you expected from the article. Thanks!
clamchowder 4y ago
Hey, author here. The Snapdragon 670, Snapdragon 821, and i5-6600K tests were done on Linux, and the rest were done on Windows. If Windows is delaying boost, it doesn't seem to be any different from Linux. And lack of intermediate states between lowest clock and max clock on all three of those (not considering the little cores) indicates the OS is not stepping through frequencies. Since people don't usually write their own OS, I don't think it's correct to take the "maximum transition latency" reported by the CPU to mean anything, because users will never observe that transition speed. Also, processors that rely on the OS (no "Speed Shift") can transition very fast if their voltages are held high to start with, suggesting most of the latency comes from waiting for voltages to increase. Please also read about Intel's "Speed Shift". While it's fairly new (only debuted in 2015), it means the CPU can clock up by itself without waiting for a transition command from the OS.
- theevilsharpie 4y ago
  > Since people don't usually write their own OS, I don't think it's correct to take the "maximum transition latency" reported by the CPU to mean anything, because users will never observe that transition speed. The Linux CPU frequency governor literally uses it as part of the algorithm for calculating its sampling rate (i.e., how frequently it checks whether to adjust the processor's frequency). > Please also read about Intel's "Speed Shift". While it's fairly new (only debuted in 2015), it means the CPU can clock up by itself without waiting for a transition command from the OS. Hardware-managed P-states don't need to wait for the OS to send a command to change the frequency, but the processor still performs periodic sampling to determine what the frequency should be (this happens ever millisecond on modern AMD and Intel hardware), the processor isn't necessarily going to choose the maximum frequency right away, and it's still subject to delays from the OS (e.g., Windows core parking). In any case, a multi-millisecond delay in switching frequency isn't because the processor is waiting for the voltage to increase.

grapescheesee 4y ago

I think it's great the author made an account today on HN, and is replying to questions from his post. This is one if the best parts of the community here. I would love to see some test done on newer CPUs, and also if any BIOS tweaks can be used to dramatically cut the time frame. It could also be interesting if you logged the PSU from the wall or the AC to DC adapter as a metric. It wouldn't be that comparable system to system. Yet it might show more linear draw vs exponential.

clamchowder 4y ago
> I think it's great the author made an account today on HN, and is replying to questions from his post. This is one if the best parts of the community here. :) > I would love to see some test done on newer CPUs So, the site is a free time thing run by several people, all of which are either students or have other full time jobs (not full time reviewers with samples of the latest hardware). No one happened to have an ICL/TGL/ADL CPU available. I do have an ADL result from earlier today showing full boost after 0.5 ms, but that person also overclocked and may have used a static voltage. Maybe we can get an addenum out with more results but I wouldn't bet on it. And yeah probably. In an extreme scenario you could just lock the CPU to its highest clock. Then you'll never see a transition period at all. > logged the PSU I don't have a power meter or PSU capable of logging
- jeffbee 4y ago
  Big fan of your site. Travis Downs has done some work on characterizing hardware transition latency. I believe his tools are on GitHub. https://travisdowns.github.io/blog/2020/01/17/avxfreq1.html https://travisdowns.github.io/blog/2020/01/17/avxfreq1.html
  - clamchowder 4y ago
    Yeah, he has some pretty interesting stuff. But AVX512 transition latency is pretty different from clocking up from idle. The CPU is already running at full tilt, and is making a relatively small frequency/voltage change. You can see from his writeup that it's well under a millisecond. I believe newer Intel CPUs have done away with AVX-512 downclocking completely. I probably won't be able to look into that specific issue since I don't have any AVX-512 capable CPUs.