News - HWBot benchmarks ban Windows 8 results because of dodgy RTC

[HEXUS]

Changing CPU frequency can have a BIG impact on Windows 8’s time accuracy.

Read more.

[scaryjim]

Curiously, of course, what this bug actually does is make overclocked systems appear to take longer to do work, and underclocked system take less time. So it would cause Intel/Win8 systems to benchmark slower than expected when overclocked.

Makes you wonder what changes MS have made and why those changes *don't* impact AMD systems...

[kalniel]

Makes you wonder what changes MS have made and why those changes *don't* impact AMD systems...

And how on earth they are ignoring the hardware RTC?! Yes, by all means have a back up for those systems that don't have one, but to ignore one when they're present in all desktop computers is just bizarre - everything in a PC should be timed from the initial hardware RTC so this is really grabbing at quite a deep level from microsoft (if it's them).

[sirtrouserpress]

Moral of the story is buy AMD, and I already do!
However it does seem more like an error with the chipset than the operating system

[kalniel]

Moral of the story is buy AMD, and I already do!
However it does seem more like an error with the chipset than the operating system

Except RTC on the chipsets all work fine for windows 7, XP, linux etc.

[TheAnimus]

It's about not reading the RTC because during the day they assumed that these frequencies wouldn't change. That is the problem. Not talking to the RTC makes things faster, and if you've got a clock of 200mhz +/-0.001% time keeping won't matter once it's been divided down in to the ticks.

[crossy]

Moral of the story is buy AMD, and I already do!
However it does seem more like an error with the chipset than the operating system

Chipset should be okay surely otherwise us "stick in the muds" who are still running "old" Windows 7 would have seen this.

More likely - to my very limited knowledge - that there's a driver somewhere deep in the guts of Windows8 for the newer Intel chipsets that is on the fritz. And I'm going to assume (perhaps a big assumption) that this might have been supplied by Intel - mainly because I'd assume some degree of commonality between MS' AMD and Intel teams.

[watercooled]

I wonder if/how many other benchmarks are impacted by this? Presumably, a lot of websites have been testing with Windows 8, and this could have skewed an awful lot of results.

I think the point is that Windows 8 isn't completely relying on the chipset RTC, as mentioned in the article and in previous posts, rather using something which can vary significantly/isn't intended for this purpose.

Edit: I wonder if spread-spectrum will cause similar problems?

[TonyB56]

I don't think you guys have read it properly.

The RTC error is manifested if you change your CPU base clock in software after booting.

unless you're overclocking with software in Windows 8/8.1 it doesn't affect the RTC.

Intel systems have always been more sensitive to clock frequency changes than AMD

[Ksyruz]

This is really odd as my most windows clocks are updated by servers, as we are always connected to the internet. Thus a simple method would be for benchmarking software to use server clocks for Windows 8 systems.

[watercooled]

I don't think you guys have read it properly.

The RTC error is manifested if you change your CPU base clock in software after booting.

unless you're overclocking with software in Windows 8/8.1 it doesn't affect the RTC.

Intel systems have always been more sensitive to clock frequency changes than AMD

I read and understood it properly, and the problem might have limited scope, but the cause is concerning. Accurate time is required for some applications, and MS chose to use a potentially very unreliable timekeeping method. It's not really fair to blame Intel if something they never intended to be used for timekeeping, happens to be inaccurate for timekeeping...

This is really odd as my most windows clocks are updated by servers, as we are always connected to the internet. Thus a simple method would be for benchmarking software to use server clocks for Windows 8 systems.

Local time is only synced occasionally (once per week according to my default registry settings), not constantly. That system generally expects systems to hold roughly correct time for more than a few minutes!

Time drift can cause some real problems, including certain encryption/authentication systems, for example TOR.

[TonyB56]

I'm not blaming Intel at all, I use both systems Intel and AMD, in fact I'm on an i73770 Win 8 system at the moment. Intel have warned overclockers before about taking care when overclocking as an extreme overclock can cause clock timing problems in the CPU. I have run some tests out of curiosity using the BIOS for clocking (base clock, multiplier and combinations of both) and there was no significant differences in the benchmarks, in Win 8 they were all within 4/5 points of each other irrespective of the method used and the RTC showed no variations at all so the problem seems to be in using overclocking software in windows itself.

[watercooled]

I didn't that as an argument against your comment BTW, I was just speaking in general.

[kalniel]

Edit: I wonder if spread-spectrum will cause similar problems?

Should average out the same hopefully, so eliminate time-drift, but depending on polling rate, could mess up audio.

Benchmarks are trivial (to me), but this could be majorly bad news for anyone working with audio or any other time-dependant operations. Windows has never been the best for that anyway due to lack of real time kernel, but it's generally been good enough.

[TheAnimus]

I read and understood it properly, and the problem might have limited scope, but the cause is concerning. Accurate time is required for some applications, and MS chose to use a potentially very unreliable timekeeping method. It's not really fair to blame Intel if something they never intended to be used for timekeeping, happens to be inaccurate for timekeeping...

It was my understanding that this is only a problem because people were changing the clock speed after the kernel had started, with an API that the kernel is 'ignorant' about.

Ultimately if it is set in the BIOS windows will work correctly and accurately. It is an odd 'issue' because it requires ring 0 privs to exploit, and if you have those all bets are off.

If you are letting the Kernel APM actually manage these things, you are fine, your timing is fine.

Unless I've miss understood something here? I'll be honest I've not written a device driver in a few years now, so am a little rusty, but fairly sure most people really don't understand wtf they are talking about ITT.

[kingpotnoodle]

If I read it correctly it originates from altering the BCLK once in Windows, which IIRC isn't supported since the demise of the FSB and for power saving only multiplier manipulation is done. Puzzled though to see Wolfdale on the list, they only mention BCLK in their write up that I can see, Wolfdale was the last throes of FSB.

If people are doing something unsupported and there is a weird interaction between Windows 8 and the Intel RTC implementation... can't really slate anyone that much when something totally unsupported doesn't work that well.