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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDghPy-uwkM


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

win-zenbook

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8986869492651053296

=== BISECT JOB RESULTS ===
NO Perf regression found

Bisect Details
  Configuration: winx64_zen_perf_bisect
  Benchmark    : kraken
  Metric       : Total/Total

Revision             Result                  N
chromium@451767      1571.68 +- 275.622      21      good
chromium@451852      1552.32 +- 60.3736      21      bad

To Run This Test
  src/tools/perf/run_benchmark -v --browser=release_x64 --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests kraken

Debug Info
  https://chromeperf.appspot.com/buildbucket_job_status/8986869492651053296

Is this bisect wrong?
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5884443031502848


| O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq
|  X  | for more information addressing perf regression bugs. For feedback,
| / \ | file a bug with component Speed>Bisection.  Thank you!

+simonhatch: looks like the bisect is giving up at the first step?
It did definitely identified a good and bad revision, but why did that stop?

re: #c4

Looks like it stopped because it had no confidence this was an actual regression. Looking at the graph, the ref build moved pretty much in sync with this.

Just curious, where do you see that it definitely identified a good/bad revision? If it's the good/bad tags maybe we should make it clearer that those are the user supplied good/bad reference revisions somehow.

As Simon already mentioned: The ref build also moves so this has something to do with the hardware.