Hmm.. this sounds like a bug. I'll try to investigate.

Yes, I'm able to reproduce. The problem happens during metric computation in clock_sync_manager.html

+charliea, +benjhayden for pointers as you seem to have experience with this file.

The error message there is:

(WARNING) 2018-06-06 14:15:34,846 timeline_based_measurement._ComputeTimelineBasedMetrics:316  Processing resulting traces took 1.334 seconds
Failure recorded: TraceImportError: No clock sync markers exist pairing clock domain "LINUX_FTRACE_GLOBAL" with target clock domain "TELEMETRY".
    at ClockSyncManager.getTimeTransformerRaw_ (/tracing/model/clock_sync_manager.html:176:15)
    at ClockSyncManager.getModelTimeTransformer (/tracing/model/clock_sync_manager.html:159:19)
    at FTraceImporter.importEvents (/tracing/extras/importer/linux_perf/ftrace_importer.html:349:40)
    at importer (/tracing/importer/import.html:198:65)
    at task.subTask (/tracing/importer/import.html:145:32)
    at Task.run (/tracing/base/task.html:80:50)
    at Function.Task.RunSynchronously (/tracing/base/task.html:125:25)
    at Import.importTraces (/tracing/importer/import.html:74:17)
    at createModelFromTraceData (/usr/local/google/code/clankium/src/third_party/catapult/tracing/tracing/mre/map_single_trace_cmdline.html:38:9)
    at eval (/usr/local/google/code/clankium/src/third_party/catapult/tracing/tracing/mre/map_single_trace_cmdline.html:57:25)

I'll look into this and report back.

It looks like the only clock sync marker in the trace generated is the one by Telemetry. There's a function to generate a dot graph of the clock sync graph in the trace, and I've attached that to this comment. 

Deleted: Screen Shot 2018-06-07 at 12.39.42 PM.png 47.6 KB

	Screen Shot 2018-06-07 at 12.39.42 PM.png 47.6 KB View Download

(Note that in the above graph, there's no clock sync marker on the Chrome or ftrace side at all)

It appears that the problem is that there basically is no ftrace at all: I've attached the ftrace file and it only has two lines. Juan, do you have any idea why we might be failing to generate an ftrace on L?

Deleted: xxyz.1 730 bytes

xxyz.1 730 bytes Download

Assigning back to Juan: this doesn't appear to be a problem with the clock sync so much as it is a problem with ftrace not collecting the data we need it to in order to run the webview startup benchmark.

Any update? I suspect our startup time differs significantly across different platform levels due to ART class verification issues, so I'd like to check our performance on L.

Sorry, haven't had time to look at this and TBH I'm not super familiar with how metrics work for this system_health.webview_startup benchmark.

changwan, is this something you could have a look at?

I ran into the same issue today.

I have no idea why ftrace doesn't work. Do we run startup benchmark on L for Chrome?
If so we should be able to run the same logic.

I don't think we have bots running benchmarks on L any more [1]. There is a N5 bot running Android K here:
https://ci.chromium.org/buildbot/chromium.perf/Android%20Nexus5%20Perf/

this one runs Chrome's "startup benchmark" (but AFAIK it's quite different from WebView's), e.g. data here:
https://chromeperf.appspot.com/report?sid=3c1d974b37c6c5ddc3af8340db6ce575197858b56b4247b3811452bd454fa313

+pasko in case we want to know more about measuring startup on Chrome.


[1]: https://chromium.googlesource.com/chromium/src/+/master/docs/speed/perf_lab_platforms.md

I don't know the issue with ftrace on L. I know that we don't have cycles to test for all platform releases, we pick just one, modulo exceptions like Go. We chose M when it was the most popular, and now N is the most popular, so we are a bit backwards on this one.

The old startup benchmarks (start_with_url.*) would work on L .. I think (they don't rely on clock sync), but their traces are very basic and not extendable. In the meantime we are switching those old benchmarks to the new infra soonish, which would likely mean .. no L.

Looks like some of the K bots are trying to run the new startup benchmarks and failing, e.g., here: https://chrome-swarming.appspot.com/task?id=407b959394267e10&refresh=10&show_raw=1

Could we selectively disable these on old dessert releases?

Re #14: Filed  issue 894744  for the problem with the new benchmark.