I'm guessing this is another ham-fisted Surface decision that was forced onto the Windows 8 developers.
Windows 8 Benchmark Records No Longer Accepted
11–20 of 31 posts
Re: Windows 8 Benchmark Records No Longer Accepted
#12These benchmarking guys are not typical Windows uses. Regular users probably appreciate NTP updates.
Re: Windows 8 Benchmark Records No Longer Accepted
#13Earlier quoted context omitted.
Windows only reads clock at startup and writes it shutdown.
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.
> 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.
Re: Windows 8 Benchmark Records No Longer Accepted
#14I'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?
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.
Re: Windows 8 Benchmark Records No Longer Accepted
#15I'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?
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.
Re: Windows 8 Benchmark Records No Longer Accepted
#16Earlier quoted context omitted.
Windows only reads clock at startup and writes it shutdown.
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.
Yep this is know problem on Android, relaying on system time for synchronizing is bad idea. One such example http://opensignal.com/reports/timestamps/
Re: Windows 8 Benchmark Records No Longer Accepted
#17Isn'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.
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.
Re: Windows 8 Benchmark Records No Longer Accepted
#18So 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.
Re: Windows 8 Benchmark Records No Longer Accepted
#19This 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/
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.
Re: Windows 8 Benchmark Records No Longer Accepted
#20Earlier quoted context omitted.
Windows only reads clock at startup and writes it shutdown.
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.
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.