See also  crbug.com/537446  - we might want a blocking relationship here.

Sorry, to clarify, scrolling_tough_ad_cases performs multiple scrolls per test.
We should consider doing this.

It seems like there're a few things to talk about here:

1) how to get stable values in face of noise better. right now we track absolute latency, in walltime. what if we could track the slices that were involved in the scroll, e.g. the critical path? We know that cpu time is lower noise. And, if we could track cpu time for input scrolls, we could be getting better data to help with, eg. advising android team on the impact of descheds on input latency.

2) whether to change when we scroll. if we do that then we're just avoiding the problem, and not realistically simulating what users do... maybe thats good because we would catch other regressions, but lets be clear about our intent and consequences of changing our definitions. :)

Yeah, there are a bunch of non-obvious decisions here.

The most obvious change is to get more samples per page load, which should be relatively straightforward.

1. Tracking the critical path might be doable, but it would make our telemetry benchmarks deviate from our UMA metrics, and they're currently the same. Ideally we'd preserve this property.

2. I agree that this would be avoiding the problem, but I'm not sure it's possible to include load without adding a huge amount of noise. It's worth experimenting with at least.