diff options
author | Tom Ritter <tom@mozilla.com> | 2018-03-06 16:29:55 -0600 |
---|---|---|
committer | wolfbeast <mcwerewolf@gmail.com> | 2018-03-14 13:17:37 +0100 |
commit | ea3585702f77a860c48c5e83d774a603fe6ebecb (patch) | |
tree | a2e1a2a11fd3fbd7ad10f408a6a3503c18e8282f | |
parent | 07148526de8085dc4e36169560805d541d272624 (diff) | |
download | UXP-ea3585702f77a860c48c5e83d774a603fe6ebecb.tar UXP-ea3585702f77a860c48c5e83d774a603fe6ebecb.tar.gz UXP-ea3585702f77a860c48c5e83d774a603fe6ebecb.tar.lz UXP-ea3585702f77a860c48c5e83d774a603fe6ebecb.tar.xz UXP-ea3585702f77a860c48c5e83d774a603fe6ebecb.zip |
Bug 1437105 - Remove flaky timing tests from ESR branch that sometimes fail with time clamping. r=baku, a=test-only
Because we hardcode time clamping in ESR (as opposed to having a pref) I
don't see a way to guarentee that this test won't fail when we lose the
race and clamp downwards.
MozReview-Commit-ID: IMwejbOBmDu
-rw-r--r-- | dom/performance/tests/test_worker_performance_now.js | 48 |
1 files changed, 1 insertions, 47 deletions
diff --git a/dom/performance/tests/test_worker_performance_now.js b/dom/performance/tests/test_worker_performance_now.js index c2a905031..dee4efce6 100644 --- a/dom/performance/tests/test_worker_performance_now.js +++ b/dom/performance/tests/test_worker_performance_now.js @@ -26,51 +26,5 @@ var n = self.performance.now(), d = Date.now(); ok(n >= 0, "The value of now() should be equal to or greater than 0."); ok(self.performance.now() >= n, "The value of now() should monotonically increase."); -// The spec says performance.now() should have micro-second resolution, but allows 1ms if the platform doesn't support it. -// Our implementation does provide micro-second resolution, except for windows XP combined with some HW properties -// where we can't use QueryPerformanceCounters (see comments at mozilla-central/xpcom/ds/TimeStamp_windows.cpp). -// This XP-low-res case results in about 15ms resolutions, and can be identified when perf.now() returns only integers. -// -// Since setTimeout might return too early/late, our goal is that perf.now() changed within 2ms -// (or 25ms for XP-low-res), rather than specific number of setTimeout(N) invocations. -// See bug 749894 (intermittent failures of this test) -var platformPossiblyLowRes; -workerTestGetOSCPU(function(oscpu) { - platformPossiblyLowRes = oscpu.indexOf("Windows NT 5.1") == 0; // XP only - setTimeout(checkAfterTimeout, 1); -}); -var allInts = (n % 1) == 0; // Indicator of limited HW resolution. -var checks = 0; +workerTestDone(); -function checkAfterTimeout() { - checks++; - var d2 = Date.now(); - var n2 = self.performance.now(); - - allInts = allInts && (n2 % 1) == 0; - var lowResCounter = platformPossiblyLowRes && allInts; - - if ( n2 == n && checks < 50 && // 50 is just a failsafe. Our real goals are 2ms or 25ms. - ( (d2 - d) < 2 // The spec allows 1ms resolution. We allow up to measured 2ms to ellapse. - || - lowResCounter && - (d2 - d) < 25 - ) - ) { - setTimeout(checkAfterTimeout, 1); - return; - } - - // Loose spec: 1ms resolution, or 15ms resolution for the XP-low-res case. - // We shouldn't test that dt is actually within 2/25ms since the iterations break if it isn't, and timeout could be late. - ok(n2 > n, "Loose - the value of now() should increase within 2ms (or 25ms if low-res counter) (delta now(): " + (n2 - n) + " ms)."); - - // Strict spec: if it's not the XP-low-res case, while the spec allows 1ms resolution, it prefers microseconds, which we provide. - // Since the fastest setTimeout return which I observed was ~500 microseconds, a microseconds counter should change in 1 iteretion. - ok(n2 > n && (lowResCounter || checks == 1), - "Strict - [if high-res counter] the value of now() should increase after one setTimeout (hi-res: " + (!lowResCounter) + - ", iters: " + checks + - ", dt: " + (d2 - d) + - ", now(): " + n2 + ")."); - workerTestDone(); -}; |