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

=== BISECT JOB RESULTS ===
Perf regression found but unable to narrow commit range

Build failures prevented the bisect from narrowing the range further.


Bisect Details
  Configuration: android_webview_nexus6_aosp_perf_bisect
  Benchmark    : system_health.common_mobile
  Metric       : clock_sync_latency_linux_clock_monotonic_to_telemetry_avg/browse_shopping/browse_shopping_amazon
  Change       : 63.53% | 1.80764928593 -> 2.73678914258

Suspected Commit Range
  10 commits in range
  https://chromium.googlesource.com/chromium/src/+log/e376d0d827d67f26c4c47d01e9ea20f6af5adbff..a0d277c259513b9c1db41ffd882d82f633cd9e11


Revision             Result                   N
chromium@526525      1.80765 +- 0.470579      14       good
chromium@526552      1.80512 +- 0.427834      14       good
chromium@526568      1.85146 +- 0.627859      21       good
chromium@526575      1.81073 +- 0.821714      21       good
chromium@526578      1.77957 +- 0.500637      14       good
chromium@526580      1.78379 +- 0.822442      21       good
chromium@526581      ---                      ---      build failure
chromium@526582      ---                      ---      build failure
chromium@526583      ---                      ---      build failure
chromium@526584      ---                      ---      build failure
chromium@526585      ---                      ---      build failure
chromium@526586      ---                      ---      build failure
chromium@526587      ---                      ---      build failure
chromium@526588      ---                      ---      build failure
chromium@526589      ---                      ---      build failure
chromium@526590      2.23144 +- 2.92808       21       bad
chromium@526645      2.73679 +- 4.27779       14       bad

To Run This Test
  src/tools/perf/run_benchmark -v --browser=android-webview --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=browse.shopping.amazon system_health.common_mobile

More information on addressing performance regressions:
  http://g.co/ChromePerformanceRegressions

Debug information about this bisect:
  https://chromeperf.appspot.com/buildbucket_job_status/8957769886686254592


For feedback, file a bug with component Speed>Bisection

Hi Reilly,

~15 days ago, there was a regression on Linux where clock sync latency between the BattOr and the computer it's attached to increased from ~0.6ms to ~3ms. Unfortunately, there were build failures in the revision range, which make it impossible to bisect over. The revision range is here: https://chromium.googlesource.com/chromium/src/+log/e376d0d827d67f26c4c47d01e9ea20f6af5adbff..a0d277c259513b9c1db41ffd882d82f633cd9e11

It seems like your CL is by far the most likely culprit in there. From the looks of your CL, it was intended to be a no-op. Is it possible that it caused this regression? Is there anything I can do on the BattOr code side to fix it? If not, is it possible to revert it?

Is BattOr using HID? I thought it was serial.

You're right, but yours seems to be the only CL of the bunch that seems to have the vague potential to regress clock sync latency. I'm not sure If HID and serial are related at all. When I'm at my Linux workstation tomorrow, I can try to revert the CL locally and see if it affects clock sync latency.

Thanks for checking it out. HID and serial don't share any of the changed code (only some unrelated infrastructure for device discovery) so it shouldn't have had an effect.

Looking at this, I realize that I made a couple of stupid mistakes when looking at this the first time:

1) This has nothing to do with BattOr. Rather, it has to do with the clock sync latency between an Android device and Telemetry. Based on this, I'm removing Reilly from the thread. Sorry about the disruption, Reilly.

2) It seems pretty regular that the clock sync latency on Android fluctuates between 2ms and 6ms based on https://chromeperf.appspot.com/report?sid=f526cf8b10dcb4be36d102f689f21f088240d9e00b5b00107c2b666b72419fa4&start_rev=515862&end_rev=530449. In fact, it seems more the norm than the exception. For a brief, inexplicable period on the Webview bots, the clock sync latency variation went way down. It's now returned to what it was before.

Based on all of this, I'm going to close this as WontFix. Even if we do manage to track down a regression, it wouldn't really be a high-value one.