All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=830798

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=3d0356243164594a30bd3321c7f932ede3edd6b28309a0806e7fc2ba7ee05fc4


Bot(s) for this bug's original alert(s):

chromium-rel-win8-dual

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/12bb452cc40000

📍 Couldn't reproduce a difference.
https://pinpoint-dot-chromeperf.appspot.com/job/12bb452cc40000

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14d1fb5cc40000

Trying on a wider range, as this got noisier.

📍 Couldn't reproduce a difference.
https://pinpoint-dot-chromeperf.appspot.com/job/14d1fb5cc40000

Tim, here's a huge EQT regression that doesn't repro at all on bisect, any ideas?

The metric is WAI.

There's a massive long task in the traces with the regression that doesn't exist in the traces without.

These traces don't have enough data to debug further though.

ThreadControllerImpl::DoWork
"../../third_party/WebKit/Source/core/script/ScriptRunner.cpp"

It isn't clear to me who should own digging into cases like this. It's a difference in the behavior of the page across multiple runs.

+Charlie, Ned, benchmark owners: In this case, the metric is working as intended, but the page behaves differently across multiple runs. This means that we can't bisect the root cause of the regression. What should be done in this case?

Finding out the causes of the instability seems to fit into soundwave scope.

However, debugging these type of problem usually requires lot of work, I would say the best we can do now is to record this page in the benchmark in a list somewhere to later dig into it. 

stgm. WontFix-ing this for now.