4 ms·

I'm a little confused. Does Windows 8 initially use the real time clock and the MHz as reference without checking if the MHz does change over time?

by ohwp 13y ago

dz0ny 13y ago
Hardware RTC(special chip on your motherboard) is used at kernel startup. Then software based RTC is used(because you can attach software interrupts to it) and this one drifts if user or system changes main system clock BCLK(sometimes called FSB). It is normal for clock to drift 10s for a period of one week, but not for period of five minutes. Example from article: By underclocking the BLCK of a Haswell system from 130MHz to 122MHz (-6%), Windows 8 loses 18 seconds over a five minute period; and the inverse applies to overclocking, too. This does not apply for Windows 7, which adjusts itself fine.
mjg59 13y ago
The Time Stamp Counter on modern CPUs runs at the same speed regardless of the CPU frequency or idle state, providing that the base clock isn't modified. Under normal use, that's absolutely fine - the OS can calibrate its internal clock against a wall clock timesource at boot time, and then use the TSC (which is very cheap to read, unlike the actual RTC) as a reliable time source. The problem here is (apparently) that calls that used to cause Windows to read the RTC now give you a TSC-based time instead. If the TSC speed has changed since boot (which should only happen if the user has explicitly changed the CPU base clock, never under normal use) then you have no way to calibrate the OSes idea of time against an actual time source. This is a problem if you're trying to perform accurate benchmarks when under/overclocking. So yeah, Windows 8 appears to use the CPU TSC without recalibrating when there's a change in TSC tick rate, but that's because the TSC tick rate isn't supposed to change.
- ambrop7 13y ago
  > So yeah, Windows 8 appears to use the CPU TSC without recalibrating when there's a change in TSC tick rate, but that's because the TSC tick rate isn't supposed to change. Right - I'd say that the problem they're having is just a bug in the program they use to change the tick rate at runtime, that is, not making the kernel aware of the change. The article is written as if there is something fundamentally wrong with clock implementation on Win8.
  - wmf 13y ago
    Because the TSC speed is never supposed to change at runtime, I would guess there is no API to notify Windows that you changed it.

I'm a little confused. Does Windows 8 initially use the real time clock and the MHz as reference without checking if the MHz does change over time?

by ohwp 13y ago

I'm a little confused. Does Windows 8 initially use the real time clock and the MHz as reference without checking if the MHz does change over time?

dz0ny 13y ago

Hardware RTC(special chip on your motherboard) is used at kernel startup. Then software based RTC is used(because you can attach software interrupts to it) and this one drifts if user or system changes main system clock BCLK(sometimes called FSB). It is normal for clock to drift 10s for a period of one week, but not for period of five minutes. Example from article: By underclocking the BLCK of a Haswell system from 130MHz to 122MHz (-6%), Windows 8 loses 18 seconds over a five minute period; and the inverse applies to overclocking, too. This does not apply for Windows 7, which adjusts itself fine.

mjg59 13y ago

The Time Stamp Counter on modern CPUs runs at the same speed regardless of the CPU frequency or idle state, providing that the base clock isn't modified. Under normal use, that's absolutely fine - the OS can calibrate its internal clock against a wall clock timesource at boot time, and then use the TSC (which is very cheap to read, unlike the actual RTC) as a reliable time source. The problem here is (apparently) that calls that used to cause Windows to read the RTC now give you a TSC-based time instead. If the TSC speed has changed since boot (which should only happen if the user has explicitly changed the CPU base clock, never under normal use) then you have no way to calibrate the OSes idea of time against an actual time source. This is a problem if you're trying to perform accurate benchmarks when under/overclocking. So yeah, Windows 8 appears to use the CPU TSC without recalibrating when there's a change in TSC tick rate, but that's because the TSC tick rate isn't supposed to change.

ambrop7 13y ago
> So yeah, Windows 8 appears to use the CPU TSC without recalibrating when there's a change in TSC tick rate, but that's because the TSC tick rate isn't supposed to change. Right - I'd say that the problem they're having is just a bug in the program they use to change the tick rate at runtime, that is, not making the kernel aware of the change. The article is written as if there is something fundamentally wrong with clock implementation on Win8.
- wmf 13y ago
  Because the TSC speed is never supposed to change at runtime, I would guess there is no API to notify Windows that you changed it.