There are a number of time/date/timer related test failures on Windows 8. There is speculation in bug 793735 comment 36 and bug 831404 comment 56 that something about time/date/timer behavior is behaving differently on Windows 8 compared with other Windows builds. Anyway, opening this bug to track all the issues. Many will say "the tests are flawed because they are relying on the behavior of timers and wall times." While there is some truth to that (and tests will likely be changed), there is still the underlying problem that time/date/timer behavior on Windows 8 is different than other Windows versions. I imagine this could have implications for setTimeout and other highly-relied-upon features.

I've looked a little bit into the various issues linked here and my bets guess is that something must have changed in the way the QueryPerformanceCounter() reports time in Windows 8; let me elaborate on this. In both PR_Now() (which is used for Date.now()) and TimeStamp::Now() we use three distinct clocks on windows: GetTickCount[64]() and QueryPerformanceCounter() for TimeStamp::Now() and GetSystemTimeAsFileTime() for PR_Now() (with a fallback if the function is not available but that shouldn't be the case on Win8). Mixing different clocks is obviously quite problematic so in TimeStamp we try to harmonize the results of GetTickCount() and QueryPerformanceCounter() because the latter can fluctuate and has other known issues... except that we turn off the harmonization under certain conditions (see HasStableTSC()): https://mxr.mozilla.org/mozilla-central/source/xpcom/ds/TimeStamp_windows.cpp#466 So my guess is that QueryPerformanceCounter() might be returning borked timings which are not verified to be coherent with GetTickCount() thus leading to incorrect timestamps. There's a few things that I need to verify to prove this theory: first of all I have to check what HasStableTSC() returns on Windows 8. If the answer is "always true" then we should be using QueryPerformanceCounter() alone for computing the duration between TimeStamps skipping the checks that compare them to GetTickCount(). Now if that's the case and QueryPerformanceCounter() fluctuates I guess we might be getting a duration between two TimeStamps that could be significantly off compared with the same duration measured with PR_Now(). Obviously there's a lot of ifs in the above and I need a Win8 machine to verify them so I'll try to get my hands on one ASAP.

(In reply to Gabriele Svelto [:gsvelto] from comment #1) > I've looked a little bit into the various issues linked here and my bets .... > Obviously there's a lot of ifs in the above and I need a Win8 machine to > verify them so I'll try to get my hands on one ASAP. Gabriele, what is your progress here? I have an older win8 machine available. I was also using it to check how QPC behaves after my most recent changes to the windows timestamp code (bug 836869) and it appeared to work well - or at least expectedly good. Is our win8 set of machines using a different hardware? I can write some simple programs to run them on our test machines and see how the timer functions behave.

(In reply to Honza Bambas (:mayhemer) from comment #2) > Is our win8 set of machines using a different hardware? Yes - win7 and winxp are currently running on Mac minis, win8 is running on some sort of new standard for our Windows slaves, win7 will move to running on those soon, then winxp.

We're running Windows 8 on iX multi-node systems which we have racked in our datacenters. Today we have enabled Windows 7 on this same hardware across the board. The jobs will be seen in here: https://tbpl.mozilla.org/?tree=Mozilla-Inbound&jobname=Windows%207%2032-bit We would like to stop running jobs on Rev3 minis by next week if there are no blockers found. We could keep running certain suites on a certain branch if it would help to debug some of these differences.

(In reply to Honza Bambas (:mayhemer) from comment #2) > Gabriele, what is your progress here? I have an older win8 machine > available. I was also using it to check how QPC behaves after my most > recent changes to the windows timestamp code (bug 836869) and it appeared to > work well - or at least expectedly good. I got myself a copy of Windows 8 but didn't have the time to install yet; the idea was to run it on my laptop. My patches for bug 793735 re-landed 5 days after your change to the windows timestamp code and the weird behavior we had experienced earlier did not show up anymore (bug 859863). My guess is that your patch made sure that the timings we got with QueryPerformanceCounter() were reliable and could be mixed with the other timings.

(In reply to Gabriele Svelto [:gsvelto] from comment #5) > My patches for bug 793735 re-landed 5 days after your change to the windows > timestamp code and the weird behavior we had experienced earlier did not > show up anymore (bug 859863). My guess is that your patch made sure that the > timings we got with QueryPerformanceCounter() were reliable and could be > mixed with the other timings. That is a great news. I knew the old fault detection code was too sensitive, the new one is much smarter. So, it seems problems are solved?

(In reply to Honza Bambas (:mayhemer) from comment #6) > That is a great news. I knew the old fault detection code was too > sensitive, the new one is much smarter. So, it seems problems are solved? Yes but let's keep our fingers crossed :)

There are issues with overclocked computers and QueryPerformanceCounter in Windows 8 that Mozilla should be aware of. See http://www.ocaholic.ch/modules/smartsection/item.php?page=0&itemid=1071 Related to Windows XP and Server 2003 support, I have also submitted: https://bugzilla.mozilla.org/show_bug.cgi?id=1014111 (Firefox only uses 32-bits of the 64-bits that GetTickCount actually returns.)

Looks like this is all fixed now – or is something missing yet?

This dormant bug seems to hold no value being open.