Windows 8 Benchmark Records No Longer Accepted
hwbot.org
hwbot.org
http://www.youtube.com/watch?v=brkDKgvXKko&feature=player_em...
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.
We lose seconds each day on our linux servers and have to use ntpd to stay in sync.
EDIT: 7% of a day is just over 1h40m.
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.
Apparently clocks are hard.
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.
You can still run hwclock on your Fedora box and get genuine RTC readout if you need it.
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?
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.
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.
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.
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.
I like this guide:
This has not been a problem with Windows 7, or XP on the same equipment.
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.