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

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


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

linux-release

 Issue 650045  has been merged into this issue.

 Issue 650047  has been merged into this issue.

 Issue 650048  has been merged into this issue.

It looks like this benchmark was disabled on mac and win, and has been failing on linux and android ref builds since Sep 16. Should it be removed altogether?

Hmm, it seems to be running successfully on Linux:

https://build.chromium.org/p/chromium.perf/builders/Linux%20Perf%20%282%29/builds/15132

Can you point me to the failures?

That bot's stdio says

"http://mashable.com": {"std": null, "name": "first_gesture_scroll_update_latency", "page_id": 5, "improvement_direction": "down", "important": true, "values": null, "none_value_reason": "Merging values containing a None value results in a None value. None values: [ListOfScalarValues(http://mashable.com, first_gesture_scroll_update_latency, ms, None, important=True, description=First gesture scroll update latency measures the time it takes to process the very first gesture scroll update input event. The first scroll gesture can often get delayed by work related to page loading., tir_label=None, std=None, improvement_direction=down, grouping_keys={})]", "units": "ms", "type": "list_of_scalar_values", "description": "First gesture scroll update latency measures the time it takes to process the very first gesture scroll update input event. The first scroll gesture can often get delayed by work related to page loading."}, 

eakuefner suggested running the benchmark locally with --browser=reference

I'm running --browser=reference now.

When I ran smoothness.scrolling_tough_ad_cases --browser=reference locally on linux, I see none_value_reasons for every page for the queueing_durations metric ("No frame queueing durations recorded."), and for every metric for the page "http://www.cnn.com/2015/01/09/politics/nebraska-keystone-pipeline/index.html".

https://x20web.corp.google.com/users/be/benjhayden/www/649979-results.json

https://codesearch.chromium.org/chromium/src/third_party/catapult/telemetry/telemetry/web_perf/metrics/smoothness.py?sq=package:chromium&dr=C&l=230

I set --output-format=json and opened the trace for the cnn page. I don't know if we have a TBMv2 version of queueing_durations, but the TBMv2 systemHealthMetrics are all perfectly well-formed and non-zero.

https://x20web.corp.google.com/users/be/benjhayden/www/649979_cnn.html

What are the next steps?
Move the smoothness benchmarks to TBMv2?
Record a fresh cnn page?

I think we can safely deprecate queueing_durations in favor of more user-facing metrics. If these problems are only there on the reference build (?), we could disable this benchmark there.

Perf sheriff ping

skyostil@: has queueing_durations been deprecated? Or, has this benchmark been disabled for the reference build on linux?

Friendly perf sheriff ping. Is there any update on #12?

We removed data stoppage alerts.