el Filou
Well-Known Member
Thread Starter
- Joined
- Dec 14, 2009
- Messages
- 262
- Likes
- 43
Hi.
I know those old CPUs are not seen much anymore but they may still be used in old HTPCs, and I recently found out the cause of many issues I have had with ReClock for 3 years since updating to Windows 10 (e.g. this one which was the worst: https://forum.redfox.bz/threads/skipping-every-4-seconds-on-mediaportal-dvb-radio.67270/) which I was finally able to fix, and was thinking I'd share my findings in case it could help someone else:
(note: I haven't used an AMD CPU since I let go of my old X2 3800+ in 2013 so I don't know how this applies to AMD)
1. Starting from 8.x, Windows will always use the CPU's TSC instruction for interval timing: https://docs.microsoft.com/en-us/wi...n-time-stamps#qpc-support-in-windows-versions because it assumes all CPUs from its time of release have a constant-rate timestamp counter. This brings problems with CPUs older than 2009/2010.
2000/XP would use the TSC by default because CPUs in that time didn't change their clock.
Vista would always use the older and slower to read, but fail-proof, platform counters (ACPI or HPET).
Windows 7 would use the TSC if it was sure that it was constant-rate, and would fall back to the platform counter otherwise.
2. All Nehalem and newer Intel CPUs have a by-design constant-rate TSC (called 'invariant') in any processor state, so they cause no problem.
Very old CPUs from the Pentium Pro to the P4 Northwood also have a de-facto constant-rate TSC because their clock speed does not change dynamically.
Between those two groups, there were the Intel CPUs on which SpeedStep and C1E were first introduced (Prescott
!): they have a TSC that is constant-rate by-design even when the internal frequency change (SpeedStep), so they should be safe, except in the following situation: when the 'Enhanced Halt State' (C1E) power saving functionality is used! Those processors are (taken from not-easy-to-find-anymore Intel datasheets):
Pentium 4 & Xeon, family 15 models 3 and higher
Core Solo & Core Duo, family 6 model 14
Xeon 5100 series & Core 2 Duo, family 6 model 15
Core 2 & Xeon, family 6 ext. model 17 (mine!)
Atom family 6
So what's happening with Windows 8+ is that even though it is only safe on those CPUs if C1E is disabled, the TSC will always be used anyway, and every time the CPU will enter C1 (which is often - you can use 'perfmon.exe' under Windows to check) it will mess up interval timing!
I started to investigate this after reading an Anandtech article this summer where they had HPET enabled by mistake instead of TSC during benchmarks and it messed with results, and I read a lot on TSC and ITSC and eventually found out the cause of my problems on obscure FreeBSD and Linux kernel dev mailing lists archives.
Another thing to know is that on those CPUs the C3 and higher states are 'Enhanced' states, so they will have the same effect (or worse, as the latency to get out of them is higher still) as C1E.
So, what is the solution? On the Intel CPU generations listed above, to avoid issues with ReClock (and probably all other video reclocking implementations like JRiver's or MediaPortal's) under Windows 8/10, you need to disable in the BIOS:
- C1E power save state
- C3+ power save states (on my ASUS P5Q PRO it is called 'Intel C-STATE Tech', not very precise wording)
SpeedStep/EIST does not cause any problems and can be left enabled to save power and extend processor life, as modern OS schedulers are designed to work with it. One error I did was disabling EIST thinking it would help but leaving C1E enabled. I still had issues with ReClock although my CPU was permanently at max clock.
For what it's worth, my Core 2 Duo E7400 only consumes 1W more when idle at stock speed with the C1E & C3 disabled compared to both enabled, and less than that when overclocked, so it's not worth it when used in anything other than a battery-powered PC.
Hope this can be helpful to someone one day via the power of Google.
Cheers!
I know those old CPUs are not seen much anymore but they may still be used in old HTPCs, and I recently found out the cause of many issues I have had with ReClock for 3 years since updating to Windows 10 (e.g. this one which was the worst: https://forum.redfox.bz/threads/skipping-every-4-seconds-on-mediaportal-dvb-radio.67270/) which I was finally able to fix, and was thinking I'd share my findings in case it could help someone else:
(note: I haven't used an AMD CPU since I let go of my old X2 3800+ in 2013 so I don't know how this applies to AMD)
1. Starting from 8.x, Windows will always use the CPU's TSC instruction for interval timing: https://docs.microsoft.com/en-us/wi...n-time-stamps#qpc-support-in-windows-versions because it assumes all CPUs from its time of release have a constant-rate timestamp counter. This brings problems with CPUs older than 2009/2010.
2000/XP would use the TSC by default because CPUs in that time didn't change their clock.
Vista would always use the older and slower to read, but fail-proof, platform counters (ACPI or HPET).
Windows 7 would use the TSC if it was sure that it was constant-rate, and would fall back to the platform counter otherwise.
2. All Nehalem and newer Intel CPUs have a by-design constant-rate TSC (called 'invariant') in any processor state, so they cause no problem.
Very old CPUs from the Pentium Pro to the P4 Northwood also have a de-facto constant-rate TSC because their clock speed does not change dynamically.
Between those two groups, there were the Intel CPUs on which SpeedStep and C1E were first introduced (Prescott
!): they have a TSC that is constant-rate by-design even when the internal frequency change (SpeedStep), so they should be safe, except in the following situation: when the 'Enhanced Halt State' (C1E) power saving functionality is used! Those processors are (taken from not-easy-to-find-anymore Intel datasheets):Pentium 4 & Xeon, family 15 models 3 and higher
Core Solo & Core Duo, family 6 model 14
Xeon 5100 series & Core 2 Duo, family 6 model 15
Core 2 & Xeon, family 6 ext. model 17 (mine!)
Atom family 6
So what's happening with Windows 8+ is that even though it is only safe on those CPUs if C1E is disabled, the TSC will always be used anyway, and every time the CPU will enter C1 (which is often - you can use 'perfmon.exe' under Windows to check) it will mess up interval timing!
I started to investigate this after reading an Anandtech article this summer where they had HPET enabled by mistake instead of TSC during benchmarks and it messed with results, and I read a lot on TSC and ITSC and eventually found out the cause of my problems on obscure FreeBSD and Linux kernel dev mailing lists archives.
Another thing to know is that on those CPUs the C3 and higher states are 'Enhanced' states, so they will have the same effect (or worse, as the latency to get out of them is higher still) as C1E.
So, what is the solution? On the Intel CPU generations listed above, to avoid issues with ReClock (and probably all other video reclocking implementations like JRiver's or MediaPortal's) under Windows 8/10, you need to disable in the BIOS:
- C1E power save state
- C3+ power save states (on my ASUS P5Q PRO it is called 'Intel C-STATE Tech', not very precise wording)
SpeedStep/EIST does not cause any problems and can be left enabled to save power and extend processor life, as modern OS schedulers are designed to work with it. One error I did was disabling EIST thinking it would help but leaving C1E enabled. I still had issues with ReClock although my CPU was permanently at max clock.
For what it's worth, my Core 2 Duo E7400 only consumes 1W more when idle at stock speed with the C1E & C3 disabled compared to both enabled, and less than that when overclocked, so it's not worth it when used in anything other than a battery-powered PC.
Hope this can be helpful to someone one day via the power of Google.
Cheers!