bit-tech.net

HWBot bans Windows 8 over RTC flaw

HWBot bans Windows 8 over RTC flaw

A flaw in the real-time clock (RTC) in Windows 8 leads to unreliable benchmark results, with HWBot the first site to refuse to accept results from the OS.

Benchmarking site HWBot has announced that Windows 8 is no longer welcome on its service, with all existing results posted from Windows 8 machines becoming invalid overnight.

Designed as a web-based league for professional overclocking, there is considerable competition for high-ranked placings in HWBot's listings. Now, however, those looking to compete will need to ensure they aren't running Microsoft's latest Windows 8 operating system - as it has been officially banned from participating.

'As the result of weekend-time research, the HWBot staff has [sic] decided to invalidate all benchmark records established with the Windows 8 operating system,' the team behind the site explained in a blog posting made late last night. 'Due to severe validity problems with the Windows 8 real time clock, benchmarks results achieved with Windows 8 cannot be trusted. The main problem lies with the RTC being affected when over- or under-clocking under the operating system. The operating system uses the RTC as reference clock, and benchmarks use it to reference (benchmark) time.'

The result: a skew on the Windows 8 real-time clock can result in a benchmark thinking more or less time has passed than in reality - meaning the benchmark results are unreliable. It's something the team has come across before: in 2010, it released an update for the HWBot Unigine Heaven wrapper, designed to make it easy to submit scores to the site, to prevent score falsification when a system was underclocked - resolving an issue in the benchmark that saw a second lasting longer than it should.

While the old bug only affected the Unigine Heaven benchmark running under Windows 7, however, this latest incarnation causes all benchmarks to report inaccurate results under Windows 8. The effect can be considerable, too: in testing, the HWBot team found that benchmarks could be skewed by over seven per cent when underclocking the processor's base clock frequency but adjusting the multiplier to keep the speed the same.

'In order to compare we need the RTC bias to be equal for all systems. With Windows 8, we can only use question marks,' the team concluded. 'Practically speaking, it is not allowed to: exploit the Windows 8 RTC for benchmark purposes; submit any benchmark results with RTC bias. The HWBOT staff will: block any seemingly out-of-line Windows 8-based benchmark results; block any Windows8-based benchmark record, even if the score seems in line with the expectations.'

The latter, of course, is the key: all Windows 8 benchmark results are now considered invalid on the site, with existing results likely to be purged from the system in the near future. Anyone looking to submit new scores to the site will need to ensure they are running an operating system unaffected by the flaw, like Windows 7.

Thus far, Microsoft has not responded to a request for comment on the apparent bug with the Windows 8 RTC - which is serious enough to cause the system clock to lose or gain time if the processor's base clock is altered away from its default.

28 Comments

Discuss in the forums Reply
Corky42 19th August 2013, 11:00 Quote
Quote:
While the old bug only affected the Unigine Heaven benchmark running under Windows 7, however, this latest incarnation causes all benchmarks to report inaccurate results under Windows 8

Sorry call me confused :? So the drift in the RTC happens under 7 as well, but they re-wrote the benchmark so as to take this into account ? and now the same thing with 8 ?

Or am i misunderstanding that the problem with 7 isn't the RTC drift, but faulty code.
fdbh96 19th August 2013, 11:01 Quote
I don't get it, why don't they just use some other form of timing system, instead of getting rid of users?

Edit: ninja'd :)
Gareth Halfacree 19th August 2013, 11:05 Quote
Quote:
Originally Posted by Corky42
Or am i misunderstanding that the problem with 7 isn't the RTC drift, but faulty code.
The problem in Windows 7 was in how an older version of Unigine Heaven addressed the RTC; the problem in Windows 8 is in the RTC itself.
Corky42 19th August 2013, 11:14 Quote
Ahhh OK, thanks for clearing that up. ;)

If the problem is with the RTC in windows 8, cant this cause all sorts of other problems ?
Or does most modern software now use the HPET.
Gareth Halfacree 19th August 2013, 11:19 Quote
Quote:
Originally Posted by Corky42
If the problem is with the RTC in windows 8, cant this cause all sorts of other problems ?
If you're fiddling with the BCLCK, then yes. The linked HWBot post shows a test that reveals just how serious the problem is: run at a higher BCLCK, and the Windows system clock starts gaining time; run at a lower BCLCK, and the Windows system clock starts losing time. Either way, you've got clock drift - and all that means for cryptography, two-factor authentication, logging etceteros.
impar 19th August 2013, 11:33 Quote
Greetings!
Quote:
Originally Posted by Gareth Halfacree
The linked HWBot post shows a test that reveals just how serious the problem is: ....
http://i.imgur.com/Dr3aBh4.png
:?
PingCrosby 19th August 2013, 11:34 Quote
I once got banned from the Working Mens Club for associating with undesirables, and one of them was a committee man, oh how we laughed
Gareth Halfacree 19th August 2013, 11:41 Quote
Quote:
Originally Posted by impar
Greetings! :?
Here, allow me:
Quote:
Originally Posted by HWBot
We can also demonstrate the Windows8 RTC problem with the Windows Time. Have a look at the videos below. In one of the videos, we underclocked the base clock frequency by 6%. After 5 minutes, Windows Time was already 18(!) seconds behind real time. When overclocking the base clock frequency, we can see the opposite effect. We overclock by roughly 4%, and after two minutes, Windows Time is 3 seconds ahead of real time.

http://www.youtube.com/embed/brkDKgvXKko
http://www.youtube.com/embed/XUi0zpRrtMM
impar 19th August 2013, 11:44 Quote
Greetings!

Bad choice of smilie. I understood the problem, was more puzzled on how wasnt this caught earlier.
Corky42 19th August 2013, 11:46 Quote
Very interesting to read the link provided in the article, this throws doubt on all benchmarks comparing 7 to 8. I wounder if Microsoft changed the way 8 measures time.
Gareth Halfacree 19th August 2013, 11:52 Quote
Quote:
Originally Posted by impar
Bad choice of smilie. I understood the problem, was more puzzled on how wasnt this caught earlier.
The trouble with clock skew is that it's subtle: your clock might gain a few minutes over a week. If you're an overclocker, the chances are good you probably don't leave your PC running for that long - you'll reboot near-daily to try new settings, install new drivers, and so forth. Each time you reboot, Windows will reset the clock from an NTP server, removing the skew - until it builds up again. As I remember it, Windows even checks in with an NTP server while the system is running - nightly? Weekly? I can't remember, somebody with Windows will have to check on that - which would mean the clock corrects itself.
Corky42 19th August 2013, 12:07 Quote
Windows checks once a week, but knowing Microsoft the NTP server is running windows so who knows how accurate it is J/K
GeorgeStorm 19th August 2013, 12:08 Quote
Quote:
Originally Posted by Gareth Halfacree
The trouble with clock skew is that it's subtle: your clock might gain a few minutes over a week. If you're an overclocker, the chances are good you probably don't leave your PC running for that long - you'll reboot near-daily to try new settings, install new drivers, and so forth. Each time you reboot, Windows will reset the clock from an NTP server, removing the skew - until it builds up again. As I remember it, Windows even checks in with an NTP server while the system is running - nightly? Weekly? I can't remember, somebody with Windows will have to check on that - which would mean the clock corrects itself.

If you've got a dedicated setup then it's likely the system will only stay powered on for a couple of hours at a time at most before a reset of some sort (either deliberate or not) :)
maverik-sg1 19th August 2013, 14:14 Quote
Benchmarking Over clockers have been exploiting software/registry workarounds to maximise their scores for years - the top ones use a stripped own OS that normal users would not even recognise and 3d settings/hacks that distort the display to a point could never actually play a game on it but it gives a higher score - most of them even sit there running PCmark tests flapping their mouse around to make one specific test produce an artificially high score.

Here's a sample of how far to go to get a good score - http://forum.overclock3d.net/showthread.php?t=35053

The skill has been finding these cheats and learning how to strip down the software to ensure the OS has enough guts to work and produce a score.

My point is, as is the way with the other "optimisations" it's real for everyone (interested in this sort of thing) so why should anyone care enough to ban it when they're all using it?

And why should Microsoft care?
Hakuren 19th August 2013, 16:11 Quote
Good one. Looking forward to world-wide ban on W8.
borandi 19th August 2013, 17:55 Quote
The issue only rears its head if you adjust BCLK while in the OS after boot, from high BCLK to low BCLK.
Quote:
most of them even sit there running PCmark tests flapping their mouse around to make one specific test produce an artificially high score.

Shows just how much you haven't kept up with it.
GoodBytes 19th August 2013, 18:49 Quote
Benchmark software problem. Not Windows 8.
Wasn't there some big story similar to that back in Vista days? Essentially saying that you can no longer run benchmarks ever again until MICROSOFT solve it, and then wrong they were, benchmark software fixed the issue, and it ended up being not Microsoft fault but rather the benchmark software maker that didn't took some things into account?

In any case, benchmark are 100% useless. Drivers detects them, and execute optimization trick, to downright force reduction of polygons, and not draw things or not properly as it should on the back that is hard to see, to gain the maximum score. Rendering benchmark software as useless as Windows Experience Index.

Real world performance is what maters. So, games for instant.
theshadow2001 19th August 2013, 20:05 Quote
Quote:
Originally Posted by GoodBytes
Benchmark software problem. Not Windows 8.
Wasn't there some big story similar to that back in Vista days? Essentially saying that you can no longer run benchmarks ever again until MICROSOFT solve it, and then wrong they were, benchmark software fixed the issue, and it ended up being not Microsoft fault but rather the benchmark software maker that didn't took some things into account?

In any case, benchmark are 100% useless. Drivers detects them, and execute optimization trick, to downright force reduction of polygons, and not draw things or not properly as it should on the back that is hard to see, to gain the maximum score. Rendering benchmark software as useless as Windows Experience Index.

Real world performance is what maters. So, games for instant.

How is the operating systems real time clock changing pace due to overclocks not an operating system problem? :|

Benchmarks are not 100% useless. Fine there may be optimisations but if everyone is running the same optimisations or selects their gear accordingly the advantage is wiped out. Real world performance is irrelevant if you are trying to achieve a high score. That is the challenge in benchmarking. Its is not about who can do an excel sheet the fastest its about getting a high score and pushing your gear to the max. Competing and comparing with others.

Honestly, sometimes I think you love Microsoft just a little bit too much.
GoodBytes 19th August 2013, 21:55 Quote
It is 100% benchmark software fault. When you decide to make a benchmark software, your measurement algorithm should not be dependent on things.

It's like you design a game but the clock rate to control the game speed, is based on clock cycle and not on actual time (remember the old computer with a Turbo button, that is why we had it. But in this case, clock system was expensive, so not every computer had it). Then you, as a developer, say how the new Intel Core i generation is crap, because your game is too fast, and unplayable. Well I am sorry.. it's your fault. Not Intel fault. Do things right, or don't do it at all.

Beside, looking at benchmark software of Windows 8 result, Windows 8 performance increase on benchmark and real world results, were marginal. So what ever HWBot is freaking out, is for 1-2 points difference, which is not normally the case. So, I call HWBot making a big deal out of nothing.
Corky42 19th August 2013, 23:41 Quote
Quote:
Originally Posted by GoodBytes
It is 100% benchmark software fault. When you decide to make a benchmark software, your measurement algorithm should not be dependent on things.

Then how would you explain the video HWBOT made, and originally linked by Gareth
Quote:
Originally Posted by HWBot
We can also demonstrate the Windows8 RTC problem with the Windows Time. Have a look at the videos below. In one of the videos, we underclocked the base clock frequency by 6%. After 5 minutes, Windows Time was already 18(!) seconds behind real time. When overclocking the base clock frequency, we can see the opposite effect. We overclock by roughly 4%, and after two minutes, Windows Time is 3 seconds ahead of real time.

http://www.youtube.com/embed/brkDKgvXKko
http://www.youtube.com/embed/XUi0zpRrtMM

No benchmark program is running, these videos show the windows clock both going to fast and to slow.
GoodBytes 20th August 2013, 01:37 Quote
Quote:
Originally Posted by Corky42
Then how would you explain the video HWBOT made, and originally linked by Gareth


No benchmark program is running, these videos show the windows clock both going to fast and to slow.

The benchmark software should adapt when measuring. The system in Windows 8, is not a bug, it's done on purpose. This is how you get things more efficient. Something that Windows 8 really needs to run on tablets and phones. Window s7 on tablets, was ****.. and I don't mean in usability. I mean general usage. There isn't 1 single Windows 7 tablet that is perfectly smooth as on a laptop, and that is with piss poor battery life, including convertible tablet that cost 3000$.
You want performance, things needs to be design more efficiently, and this is what you have.
It's all part of being more of a RT OS (real time OS). While Windows 8 isn't a true RT OS, it compromises, to balance desktop/laptop and embedded systems (tablet, phone, console, etc) (hybrid solution?). Windows CE is a real RT OS... but Windows CE has no business in laptops and desktop, and I don't think I need to explain why.
theshadow2001 20th August 2013, 02:31 Quote
The sort of time keeping required is important for benchmarks as a few points can make the difference in terms winning or losing or ranking or whatever it is benchmarkers do.

Here's a page with a few other benchmarks that have been screwed with. But of course the infallible Microsoft is right and all these other software developers are wrong because they used what was essentially a stable feature of windows 7.

Having a quick google around I'm not sure what else there is on a windows system to base a benchmark off of. I'm also not sure how a benchmark software could adapt given its base reference is skewed. At the end of it you still need reliable time measurement.

The problem is due to support for low end devices. They had to decrease the quality of time keeping in order to extend the range of compatible low end devices. Its purely a business decision. Its certainly not about efficiency. I'm sure there will be a patch for this at some stage. I'm also sure its not a priority for Microsoft.
Gareth Halfacree 20th August 2013, 10:00 Quote
Quick update: Futuremark has become the first benchmark company to respond to the ban, promising to investigate the RTC issue itself and see if it can come up with a workaround.
Quote:
Originally Posted by GoodBytes
The system in Windows 8, is not a bug, it's done on purpose. This is how you get things more efficient.
Clock skew is not a bug? Drift on the system clock is done on purpose? Because it makes things more efficient?! Yeah, that's... That's not actually true, y'know.
Quote:
Originally Posted by GoodBytes
It's all part of being more of a RT OS (real time OS).
I don't think that means what you think it means. Clock skew would be fatal to an RTOS, but that's OK because Windows 8 is most certainly not an RTOS - and neither is it designed to be.
mikemaher205 20th August 2013, 10:34 Quote
Poor Windows 8. It's almost making Vista look like a good idea... Almost, but not quite.
Corky42 20th August 2013, 11:18 Quote
Interesting to read that apparently AMD systems are not affected by this.
fdbh96 20th August 2013, 19:30 Quote
Surely you could adjust the timing element of the software by detecting by how much the BLK has been changed.
Corky42 20th August 2013, 20:55 Quote
I have been trying to find a answer to this for a couple of days now :(

Does anyone know what changed in the way Microsoft measured time from 7 to 8, and from Intel to AMD. I'm guessing they no longer use the RTC on Intel based systems. Am i correct in saying the RTC was moved into the CPU from Sandy bridge/Fusion onward ?

And if so why didn't Microsoft use the same checks used on AMD system to keep the time accurate on Intel systems ?, or is it more to do with the hardware differences from AMD to Intel that prevents Microsoft from keeping a check on the RTC ?
djzic 22nd August 2013, 10:03 Quote
Microsoft really need to pull their finger out of their arse and fix this... I mean, come on, we're talking about Windows 8, not Windows 3.1!
Log in

You are not logged in, please login with your forum account below. If you don't already have an account please register to start contributing.



Discuss in the forums