Exploring the link between C-states and latency
-
nomaddroid
- Posts: 15
- Joined: 20 Aug 2024, 07:05
Exploring the link between C-states and latency
Hello there!
I am here to share the findings from which I have curiously tinkered to find out the reason for this abnormal feeling of inconsistency with inputs, as well as the overall feel of the system. This phenomenon is not limited to one PC, but any PC that has C-states or Dynamic Tick feature enabled.
The phenomenon is the drift or delay in mouse movements which can be noticeable easily when moving the mouse in O-shape or X-shape. I am not sure if the term “Delay” is appropriate to use because it feels more like a drift in movements. Is it only with the mouse that this occurs? I think the mouse makes it easier to observe compared to other peripherals like the keyboard. Alongside this, there is also some kind of jitter which is impacting the presentation smoothness, be it games or scrolling text in a browser, making everything look like it has a subtle ghosting effect or like when there is increase in display response times.
The first time I observed, I wondered whether it was just the way it was or it was an odd Windows behavior. Interestingly, Linux felt the same way too. Was also left clueless as to why PlayStation 3 felt much smoother compared to PC even considering the steady frame pacing. After digging through a bunch of OS related features, I came to know that most modern operating systems function in “Tickless” or “Dynamic Tick” mode by default. This wasn’t a thing during PS3 days and Windows only started implementing it from Windows 8. Why show interest in this feature particularly? Because it is related to system interrupts which correlates to timings and inputs. Before Windows 8 (let’s also include PS3 because it was released priorly), interrupts were processed in “Periodic” mode, where interrupts are processed at intervals strictly based on the tick rate of the operating systems (15.625 ms default timer resolution on Windows) and continue to run even under idle states. So, out of curiosity, I went ahead and disabled this feature. To my surprise, everything felt on point, ranging from inputs to smoothness, as smooth as how I remembered PS3 games used to feel. 30 FPS on PC doesn’t feel as jerky but smooth as how PS3 presented it. Obviously, disabling the Dynamic Tick feature impacts power usage by preventing CPUs from entering idle states. And then I thought, if the Dynamic Tick feature is preventing CPUs from entering idle states, perhaps it is the “C-states” that are causing this phenomenon in the first place and not due to the interrupt rate. I went ahead and re-enabled the Dynamic Tick feature and limited C-states to C1 only (since C1 has the least transition latency). And there it is, everything snapped back to consistent behavior again, just as when Dynamic Tick is disabled.
Monitoring C-states in “HWiNFO” software shows cores enter C6 state frequently even during gameplay and of course, very frequently during idle. I am assuming that the frequent C-state induced skewed timings, cache flushes, voltage variations, PLL shut offs etc., are the reasons for the mentioned phenomenon. Nevertheless, Dynamic Tick and C-state features are the standard for every desktop PC in the market and the subtle abnormalities wouldn’t bother most users. Even PCs configured for Esports might have left these features enabled, so there’s that.
Feel free to share your thoughts.
I am here to share the findings from which I have curiously tinkered to find out the reason for this abnormal feeling of inconsistency with inputs, as well as the overall feel of the system. This phenomenon is not limited to one PC, but any PC that has C-states or Dynamic Tick feature enabled.
The phenomenon is the drift or delay in mouse movements which can be noticeable easily when moving the mouse in O-shape or X-shape. I am not sure if the term “Delay” is appropriate to use because it feels more like a drift in movements. Is it only with the mouse that this occurs? I think the mouse makes it easier to observe compared to other peripherals like the keyboard. Alongside this, there is also some kind of jitter which is impacting the presentation smoothness, be it games or scrolling text in a browser, making everything look like it has a subtle ghosting effect or like when there is increase in display response times.
The first time I observed, I wondered whether it was just the way it was or it was an odd Windows behavior. Interestingly, Linux felt the same way too. Was also left clueless as to why PlayStation 3 felt much smoother compared to PC even considering the steady frame pacing. After digging through a bunch of OS related features, I came to know that most modern operating systems function in “Tickless” or “Dynamic Tick” mode by default. This wasn’t a thing during PS3 days and Windows only started implementing it from Windows 8. Why show interest in this feature particularly? Because it is related to system interrupts which correlates to timings and inputs. Before Windows 8 (let’s also include PS3 because it was released priorly), interrupts were processed in “Periodic” mode, where interrupts are processed at intervals strictly based on the tick rate of the operating systems (15.625 ms default timer resolution on Windows) and continue to run even under idle states. So, out of curiosity, I went ahead and disabled this feature. To my surprise, everything felt on point, ranging from inputs to smoothness, as smooth as how I remembered PS3 games used to feel. 30 FPS on PC doesn’t feel as jerky but smooth as how PS3 presented it. Obviously, disabling the Dynamic Tick feature impacts power usage by preventing CPUs from entering idle states. And then I thought, if the Dynamic Tick feature is preventing CPUs from entering idle states, perhaps it is the “C-states” that are causing this phenomenon in the first place and not due to the interrupt rate. I went ahead and re-enabled the Dynamic Tick feature and limited C-states to C1 only (since C1 has the least transition latency). And there it is, everything snapped back to consistent behavior again, just as when Dynamic Tick is disabled.
Monitoring C-states in “HWiNFO” software shows cores enter C6 state frequently even during gameplay and of course, very frequently during idle. I am assuming that the frequent C-state induced skewed timings, cache flushes, voltage variations, PLL shut offs etc., are the reasons for the mentioned phenomenon. Nevertheless, Dynamic Tick and C-state features are the standard for every desktop PC in the market and the subtle abnormalities wouldn’t bother most users. Even PCs configured for Esports might have left these features enabled, so there’s that.
Feel free to share your thoughts.
Re: Exploring the link between C-states and latency
This is well known, actually. Transitioning to low CPU idle states and back can cause jitter. Pro audio people disable low power C states to avoid audio distortion when they need very low audio latency (sub 5ms.) I used to do that too when I was doing some audio work in a DAW, where I would get crackling audio with very small audio buffer sizes if I didn't limit C states.
With high refresh rate displays and 2000Hz+ mice, I can imagine that disabling C states can help. Although I don't think anyone out there has actually done proper measurements on this to get exact data.
With high refresh rate displays and 2000Hz+ mice, I can imagine that disabling C states can help. Although I don't think anyone out there has actually done proper measurements on this to get exact data.
Steam • GitHub • Stack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.
Re: Exploring the link between C-states and latency
for some reason i get worse kernel timer latency with c-state off (z790).
im use enable c-state + set c0, it feel better and fix my kernel timer latency.
im use enable c-state + set c0, it feel better and fix my kernel timer latency.
-
nomaddroid
- Posts: 15
- Joined: 20 Aug 2024, 07:05
Re: Exploring the link between C-states and latency
I agree. Some C-states have transition and exit latencies of around or above 2000 microseconds which can still be quite substantial for some workloads and cores constantly entering such C-state residencies above 50% of the times seem impactful enough. AMD CPUs supposedly only have them maxed at C6 state unlike Intel having them deeper than C6. Good thing they can be toggled off in OS without having to modify BIOS settings, where some systems give limited access to BIOS. Wonder if users that report to have "floaty" mouse feel is due C-states.RealNC wrote: ↑20 Aug 2024, 19:23This is well known, actually. Transitioning to low CPU idle states and back can cause jitter. Pro audio people disable low power C states to avoid audio distortion when they need very low audio latency (sub 5ms.) I used to do that too when I was doing some audio work in a DAW, where I would get crackling audio with very small audio buffer sizes if I didn't limit C states.
With high refresh rate displays and 2000Hz+ mice, I can imagine that disabling C states can help. Although I don't think anyone out there has actually done proper measurements on this to get exact data.
-
nomaddroid
- Posts: 15
- Joined: 20 Aug 2024, 07:05
Re: Exploring the link between C-states and latency
You can limit to C1 (not C1E) only since C0 locks the CPU frequency to its maximum and disables dynamic frequency scaling. Windows provides settings for idle promotion and demotion thresholds, setting them to 100% limit C-states to C1.
Re: Exploring the link between C-states and latency
c-state disable - cause higher kernel timer latencynomaddroid wrote: ↑20 Aug 2024, 22:42You can limit to C1 (not C1E) only since C0 locks the CPU frequency to its maximum and disables dynamic frequency scaling. Windows provides settings for idle promotion and demotion thresholds, setting them to 100% limit C-states to C1.
c-state enable + c0 state - not.
-
nomaddroid
- Posts: 15
- Joined: 20 Aug 2024, 07:05
Re: Exploring the link between C-states and latency
Interesting, when disabling idle states from Windows power options, HWiNFO shows limiting to C0 state and locking frequency to the max. When enabling idle states, frequency is scaled normally with C1 state. Also made sure to prevent CPU from entering C6 state using idle threshold setting. Maybe disabling through software is different from disabling through BIOS. Refer to attachements.Slender wrote: ↑20 Aug 2024, 23:43c-state disable - cause higher kernel timer latencynomaddroid wrote: ↑20 Aug 2024, 22:42You can limit to C1 (not C1E) only since C0 locks the CPU frequency to its maximum and disables dynamic frequency scaling. Windows provides settings for idle promotion and demotion thresholds, setting them to 100% limit C-states to C1.
c-state enable + c0 state - not.
- Attachments
-
- Windows Power Options.png (9.39 KiB) Viewed 9871 times
-
- Idle States Enabled.png (109.77 KiB) Viewed 9871 times
-
- Idle States Disabled.png (81.59 KiB) Viewed 9871 times
Re: Exploring the link between C-states and latency
By disabling "Processor Idle Disable" your CPU will increase temperature by 10 or 15º even when cpu is doing nothing.nomaddroid wrote: ↑21 Aug 2024, 00:16Interesting, when disabling idle states from Windows power options, HWiNFO shows limiting to C0 state and locking frequency to the max. When enabling idle states, frequency is scaled normally with C1 state. Also made sure to prevent CPU from entering C6 state using idle threshold setting. Maybe disabling through software is different from disabling through BIOS. Refer to attachements.Slender wrote: ↑20 Aug 2024, 23:43c-state disable - cause higher kernel timer latencynomaddroid wrote: ↑20 Aug 2024, 22:42You can limit to C1 (not C1E) only since C0 locks the CPU frequency to its maximum and disables dynamic frequency scaling. Windows provides settings for idle promotion and demotion thresholds, setting them to 100% limit C-states to C1.
c-state enable + c0 state - not.
This is a really bad idea and you gain nothing. C1 will go to C0 practically instantly.
It's possible that some modern cpus depend on C-States for certain things and if you disable them you might be making things worse. I wouldn't know, I still have an I5-4690K and for me it's better to disable them. I don't have problems with kernel latency.
If I leave them enabled in BIOS and disable them in High Performance power plan, I need to disable C1E in BIOS or else this will cause a small CPU frequency instability and never reach the full constant 3.9GHz turbo speed. I observed this with ThrottleStop app.
Through BIOS you are really disabling C-States and your C6 state will not show in HWInfo.
Through power plan you are simply avoiding entering such states but they are recognized by Windows.
- Attachments
-
- bios_c-states.jpg (133.19 KiB) Viewed 9824 times
-
nomaddroid
- Posts: 15
- Joined: 20 Aug 2024, 07:05
Re: Exploring the link between C-states and latency
Right, at least, entering deeper C-states is prevented when either properly set through software or BIOS. And yes, completely disabling C-states seem to make it worse in terms of both latency and performance despite being consistently locked at maximum supported base frequency. Intel's C-states structure seems a bit complex compared to AMD's, where, for example, they apparently have sub states for say, C1, that is, 0 (C1) and 1(C1E) and so on. Although, not sure why C1E disables boost frequency apart from it having lower transition and exit latencies than deeper C-states like C6 and C7.MatrixQW wrote: ↑21 Aug 2024, 01:27By disabling "Processor Idle Disable" your CPU will increase temperature by 10 or 15º even when cpu is doing nothing.
This is a really bad idea and you gain nothing. C1 will go to C0 practically instantly.
It's possible that some modern cpus depend on C-States for certain things and if you disable them you might be making things worse. I wouldn't know, I still have an I5-4690K and for me it's better to disable them. I don't have problems with kernel latency.
If I leave them enabled in BIOS and disable them in High Performance power plan, I need to disable C1E in BIOS or else this will cause a small CPU frequency instability and never reach the full constant 3.9GHz turbo speed. I observed this with ThrottleStop app.
Through BIOS you are really disabling C-States and your C6 state will not show in HWInfo.
Through power plan you are simply avoiding entering such states but they are recognized by Windows.
Re: Exploring the link between C-states and latency
Do you have problems with latency/performance by disabling them in power plan? Or just when you disable them in BIOS?
Does your CPU support C1E? If you don't have an option to disable it in BIOS you can do it with ThrottleStop.
What kind of latency values are you talking about and how did you measure them? Or is it more a visual/feeling thing?
As system related measurements in microseconds, this is mine and it's fine:
Does your CPU support C1E? If you don't have an option to disable it in BIOS you can do it with ThrottleStop.
What kind of latency values are you talking about and how did you measure them? Or is it more a visual/feeling thing?
As system related measurements in microseconds, this is mine and it's fine:
Code: Select all
--------------------------
DPC Info
--------------------------
CPU 0 Usage, CPU 1 Usage, CPU 2 Usage, CPU 3 Usage,
usec %, usec %, usec %, usec %, Module
5015 0.00, 1485 0.00, 546 0.00, 162 0.00, ntoskrnl.exe
Total = 2537 for module ntoskrnl.exe
Elapsed Time, > 0 usecs AND <= 1 usecs, 423, or 16.67%
Elapsed Time, > 1 usecs AND <= 2 usecs, 384, or 15.14%
Elapsed Time, > 2 usecs AND <= 4 usecs, 1332, or 52.50%
Elapsed Time, > 4 usecs AND <= 8 usecs, 93, or 3.67%
Elapsed Time, > 8 usecs AND <= 16 usecs, 297, or 11.71%
