Threshold in user-timing tests too short for slow machines

When we (Chrome/Blink) run the user-timing tests as part of our continuous integration, we frequently test failures on the user-timing tests due to steps exceeding the threshold, e.g.:

window.performance.getEntriesByName("measure_nav_start_no_end")[0].duration ~== 282 (up to 20ms difference allowed) assert_true: window.performance.getEntriesByName("measure_nav_start_no_end")[0].duration ~== 282 (up to 20ms difference allowed) expected true got false

window.performance.getEntriesByName("measure_nav_start_no_end")[0].duration ~== 225 (up to 20ms difference allowed) assert_true: window.performance.getEntriesByName("measure_nav_start_no_end")[0].duration ~== 225 (up to 20ms difference allowed) expected true got false

etc.

This occurs randomly, but most frequently on slow machines: older Windows (e.g. XP), older OSX (e.g. 10.6, 10.7) with debug builds, etc.

In the short term we'll probably just stop running these tests, but it would be nice to have an upstream solution. Simply upping the 20ms threshold would reduce the number of failures, but any suggestions welcome.

Locate the user-timing tests and the assertions comparing performance.getEntriesByName("measure_nav_start_no_end")[0].duration with expected values. Run them on a slow or debug environment to reproduce the intermittent failures, then define a stable threshold strategy and verify that the tests no longer fail spuriously without weakening their coverage.