6 ms·

Windows 8 Benchmark Records No Longer Accepted

92 points by dz0ny 13y ago

ck2 13y ago
Isn't this a problem on any os with cpu "speed stepping" ? We lose seconds each day on our linux servers and have to use ntpd to stay in sync.
- jstanley 13y ago
  Even 10 seconds a day only amounts to ~0.01% discrepancy. In this article they're reporting up to 7% if I'm reading it correctly. EDIT: 7% of a day is just over 1h40m.
- wbl 13y ago
  The real-time clock on the motherboard should correct for this.
  - dz0ny 13y ago
    Windows only reads clock at startup and writes it shutdown.
    - archivator 13y ago
      And so does my Fedora install (let's not blame Redmond unnecessarily). My Android phone is even worse - it drifts by about 5-10s a day. Not a nightmare but it's still a lot more than my (probably unrealistic) expectations of 21st century hardware.
      - freehunter 13y ago
        My car also has a drifting clock without a dynamic CPU, losing two minutes every three months. It also doesn't have the ability to sync with NTP so it can't correct itself. Apparently clocks are hard.
        harrytuttle 13y ago
        Clocks are easy. Even accurate clocks are easy. However, accurate clocks are expensive which is where the problem is
        deleted 13y ago
        [deleted]
      - dspillett 13y ago
        > And so does my Fedora install (let's not blame Redmond unnecessarily). It isn't particularly an OS probably at all at the root: it is a hardware problem. The RTCs in PC have historically not been terribly reliable so OSes tend to ignore them where at all possible. The probably here is probably the same as seen inside VMs: the OS is trying to count timer interrupts and other such references to gauge the passage of time, but with CPUs changing their speeds constantly this in itself becomes difficult to make accurate. Windows' default behaviour of occasionally checking an external time reference (IIRC it checks approximately three times per day if your machine is on 24 hours) is often inadequate IMO though. Much better would be to use proper (relatively constant) NTP checking and clock skewing, though that imposes an extra infrastructure load.
      - dz0ny 13y ago
        Yep this is know problem on Android, relaying on system time for synchronizing is bad idea. One such example http://opensignal.com/reports/timestamps/ http://opensignal.com/reports/timestamps/
      - ape4 13y ago
        I'd think it would be good for either OS to update the RTC occasionally. So when it does reboot the RTC is sort of accurate.
      - qb45 13y ago
        Here Redmond is blamed for not providing any API to access the physical RTC chip and for switching old APIs to use CPU cycle counter even on RTC-equipped systems. You can still run hwclock on your Fedora box and get genuine RTC readout if you need it.
        cnvogel 13y ago
        hwclock will only give you 1second resolution, because the RTC chip can't do better. But querying the RTC directly is dog slow by todays standards, it's accessed via 8-bit port IO where one access eats up thousands of cpu cycles on a modern chip. The really old way of timekeeping was to basically advance the system time by a constant amount, in an interrupt routine which might have been triggered by the ancient timer chip, and interpolation done between those ticks using the cpu TSCs. And actually hwclock accesses /dev/rtc* which is just an arbitrary character devices (which the kernel indeed can use to initialize its notion of time on boot up), it's never accessed with the standard syscalls gettimeofday() or clock_gettime(). So while I really like MS bashing from time to time, in this case it's probably not too negligent of them, there might even be a standard way of informing the OS kernel about a change in TSC speed?
- wmf 13y ago
  Isn't this a problem on any os with cpu "speed stepping" ? No. Recent processors have a constant TSC frequency independent of the core frequency, so it's safe to use the TSC to measure real time. Older processors can use the constant-frequency PIT or APIC interval timers.
helloNSA_ 13y ago
This has been a significant issue on the windows 8 machines I've handled. It's mitigated somewhat by creating your own scheduled task to more frequently do ntp updates. I like this guide: http://www.pretentiousname.com/timesync/ http://www.pretentiousname.com/timesync/
- Tomdarkness 13y ago
  You modify the BCLK regularly whilst booted into Windows on the different Win 8 machines you handle? Even when overclocking you'd normally not mess with the BCLK unless you are really wanting to push your overclock.
  - helloNSA_ 13y ago
    Windows 8 keeps terrible time on laptops or anything else which is trying to power save by varying the clock. I'm not overclocking shit. The OS just doesn't time sync frequently enough. This is why I posted a link about increasing the frequency of time syncs. This has not been a problem with Windows 7, or XP on the same equipment.
    - Tomdarkness 13y ago
      That is not how the power saving works. It does not vary the BCLK rather it alters the multiplier. If it varied the BCLK by such large amounts to achieve typical low power frequency levels then you'd likely run into some catastrophic stability problems as the BCLK is also used by the integrated memory controller and QPI.
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.
beedogs 13y ago
I'm guessing this is another ham-fisted Surface decision that was forced onto the Windows 8 developers.
ape4 13y ago
These benchmarking guys are not typical Windows uses. Regular users probably appreciate NTP updates.
- masklinn 13y ago
  This has nothing to do with NTP.
swat535 13y ago
So this only affects you if you change BCLK at runtime. Which is something that basically never happens unless you do it yourself explicitly. Dynamic CPU speed only modifies multiplier which does not cause this issue. This is a non-issue for 99% of people, it's only an issue if you are measuring your manhood on an internet website.
- redthrowaway 13y ago
  It's also an issue for anyone who's overclocked their gaming rig, as the computer won't keep accurate time anymore. See this video for a demonstration of that: http://www.youtube.com/watch?v=brkDKgvXKko&feature=player_embedded http://www.youtube.com/watch?v=brkDKgvXKko&feature=player_em...
  - Guvante 13y ago
    Why are you overclocking at run-time vs the simpler BIOS time overclock? Sure while you are testing stability making run-time changes is nice, but once you know what your system can handle it makes sense to just set that permanently. Also hopefully a fix will come out soon, since it is already well known that the ratio is allowed to change.
jheriko 13y ago
what, the age old problems with the rtc are not handled by windows 8 benchmarking? i feel this has been noticed nearly 20 years late... maybe its because i have been a low level guy for a while, but ffs people, know your platform before you start using random features. despite the overriding idea that platform and 'big company' apis are good there are plenty of cases where you can do much better yourself - this is why so much of games industry code is hand rolled.

92 points by dz0ny 13y ago

ck2 13y ago

Isn't this a problem on any os with cpu "speed stepping" ? We lose seconds each day on our linux servers and have to use ntpd to stay in sync.

jstanley 13y ago
Even 10 seconds a day only amounts to ~0.01% discrepancy. In this article they're reporting up to 7% if I'm reading it correctly. EDIT: 7% of a day is just over 1h40m.
wbl 13y ago
The real-time clock on the motherboard should correct for this.
- dz0ny 13y ago
  Windows only reads clock at startup and writes it shutdown.
  - archivator 13y ago
    And so does my Fedora install (let's not blame Redmond unnecessarily). My Android phone is even worse - it drifts by about 5-10s a day. Not a nightmare but it's still a lot more than my (probably unrealistic) expectations of 21st century hardware.
    - freehunter 13y ago
      My car also has a drifting clock without a dynamic CPU, losing two minutes every three months. It also doesn't have the ability to sync with NTP so it can't correct itself. Apparently clocks are hard.
      - harrytuttle 13y ago
        Clocks are easy. Even accurate clocks are easy. However, accurate clocks are expensive which is where the problem is
        deleted 13y ago
        [deleted]
    - dspillett 13y ago
      > And so does my Fedora install (let's not blame Redmond unnecessarily). It isn't particularly an OS probably at all at the root: it is a hardware problem. The RTCs in PC have historically not been terribly reliable so OSes tend to ignore them where at all possible. The probably here is probably the same as seen inside VMs: the OS is trying to count timer interrupts and other such references to gauge the passage of time, but with CPUs changing their speeds constantly this in itself becomes difficult to make accurate. Windows' default behaviour of occasionally checking an external time reference (IIRC it checks approximately three times per day if your machine is on 24 hours) is often inadequate IMO though. Much better would be to use proper (relatively constant) NTP checking and clock skewing, though that imposes an extra infrastructure load.
    - dz0ny 13y ago
      Yep this is know problem on Android, relaying on system time for synchronizing is bad idea. One such example http://opensignal.com/reports/timestamps/ http://opensignal.com/reports/timestamps/
    - ape4 13y ago
      I'd think it would be good for either OS to update the RTC occasionally. So when it does reboot the RTC is sort of accurate.
    - qb45 13y ago
      Here Redmond is blamed for not providing any API to access the physical RTC chip and for switching old APIs to use CPU cycle counter even on RTC-equipped systems. You can still run hwclock on your Fedora box and get genuine RTC readout if you need it.
      - cnvogel 13y ago
        hwclock will only give you 1second resolution, because the RTC chip can't do better. But querying the RTC directly is dog slow by todays standards, it's accessed via 8-bit port IO where one access eats up thousands of cpu cycles on a modern chip. The really old way of timekeeping was to basically advance the system time by a constant amount, in an interrupt routine which might have been triggered by the ancient timer chip, and interpolation done between those ticks using the cpu TSCs. And actually hwclock accesses /dev/rtc* which is just an arbitrary character devices (which the kernel indeed can use to initialize its notion of time on boot up), it's never accessed with the standard syscalls gettimeofday() or clock_gettime(). So while I really like MS bashing from time to time, in this case it's probably not too negligent of them, there might even be a standard way of informing the OS kernel about a change in TSC speed?
wmf 13y ago
Isn't this a problem on any os with cpu "speed stepping" ? No. Recent processors have a constant TSC frequency independent of the core frequency, so it's safe to use the TSC to measure real time. Older processors can use the constant-frequency PIT or APIC interval timers.

helloNSA_ 13y ago

This has been a significant issue on the windows 8 machines I've handled. It's mitigated somewhat by creating your own scheduled task to more frequently do ntp updates. I like this guide: http://www.pretentiousname.com/timesync/ http://www.pretentiousname.com/timesync/

Tomdarkness 13y ago
You modify the BCLK regularly whilst booted into Windows on the different Win 8 machines you handle? Even when overclocking you'd normally not mess with the BCLK unless you are really wanting to push your overclock.
- helloNSA_ 13y ago
  Windows 8 keeps terrible time on laptops or anything else which is trying to power save by varying the clock. I'm not overclocking shit. The OS just doesn't time sync frequently enough. This is why I posted a link about increasing the frequency of time syncs. This has not been a problem with Windows 7, or XP on the same equipment.
  - Tomdarkness 13y ago
    That is not how the power saving works. It does not vary the BCLK rather it alters the multiplier. If it varied the BCLK by such large amounts to achieve typical low power frequency levels then you'd likely run into some catastrophic stability problems as the BCLK is also used by the integrated memory controller and QPI.

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.

beedogs 13y ago

I'm guessing this is another ham-fisted Surface decision that was forced onto the Windows 8 developers.

ape4 13y ago

These benchmarking guys are not typical Windows uses. Regular users probably appreciate NTP updates.

masklinn 13y ago
This has nothing to do with NTP.

swat535 13y ago

So this only affects you if you change BCLK at runtime. Which is something that basically never happens unless you do it yourself explicitly. Dynamic CPU speed only modifies multiplier which does not cause this issue. This is a non-issue for 99% of people, it's only an issue if you are measuring your manhood on an internet website.

redthrowaway 13y ago
It's also an issue for anyone who's overclocked their gaming rig, as the computer won't keep accurate time anymore. See this video for a demonstration of that: http://www.youtube.com/watch?v=brkDKgvXKko&feature=player_embedded http://www.youtube.com/watch?v=brkDKgvXKko&feature=player_em...
- Guvante 13y ago
  Why are you overclocking at run-time vs the simpler BIOS time overclock? Sure while you are testing stability making run-time changes is nice, but once you know what your system can handle it makes sense to just set that permanently. Also hopefully a fix will come out soon, since it is already well known that the ratio is allowed to change.

jheriko 13y ago

what, the age old problems with the rtc are not handled by windows 8 benchmarking? i feel this has been noticed nearly 20 years late... maybe its because i have been a low level guy for a while, but ffs people, know your platform before you start using random features. despite the overriding idea that platform and 'big company' apis are good there are plenty of cases where you can do much better yourself - this is why so much of games industry code is hand rolled.