Input Event Timestamps

[Tim Dresser]

As we've been running into more issues with broken event timestamps, it's increasingly tempting to always use the timestamp from the browser process for our input latency metrics instead of the hardware timestamp provided by the OS.

We'd lose coverage of time that input is blocked on the browser UI thread, but we'd eliminate a confusing source of noise in our metrics.

I propose using the time at which input hits the browser process as the event timestamp as surfaced to JS, and as the base for all our input latency metrics. This will impact timestamps seen from JS.

Independently, we should have a metric for the delta from hardware timestamp until we see the event on the browser UI thread, to catch any regressions which do occur here.

Any thoughts? 

Tim

[Erik Chen]

Could you clarify why your proposal reduces noise in the non-Linux case? 

Reading through the bugs, it seems like we have an issue on Linux, which we have a workaround for, and the other platforms all work fine. My assumption is that most platforms probably generate the hardware timestamp the same way we'd generate the timestamp in the browser process. 

[Majid Valipour]

+Dave Tapuska reminded me of another source of potential issues.

On some platforms timestamps are not consistent across processes. So if your metrics are comparing timestamps that are recorded across processes then it should pay attention to TimeTicks::IsConsistentAcrossProcesses. (For example here ServiceWorker skips collecting metrics on such platforms).

Note that Event.timeStamp is already corrected for this so it is should be safe to compare it with timestamps from renderer process. So it depends what your metrics are measuring.

Majid

 

[Majid Valipour]

+Dave Tapuska reminded me of another source of potential issues.

On some platforms timestamps are not consistent across processes. So if your metrics are comparing timestamps that are recorded across processes then it should pay attention to TimeTicks::IsConsistentAcrossProcesses. (For example here ServiceWorker skips collecting metrics on such platforms).

Note that Event.timeStamp is already corrected for this so it is should be safe to compare it with timestamps from renderer process. So it depends what your metrics are measuring.

Majid

On Tue, Jul 24, 2018 at 11:01 AM 'Erik Chen' via input-dev <inpu...@chromium.org> wrote:

[Tim Dresser]

Windows we've always used the browser process timestamp, as drivers often provide terrible values.

We thought Linux was the only issue, but Android and Chrome OS also provide bad timestamps. On certain Android devices, we see ~60% of event timestamps are obviously incorrect.

We are using event.timeStamp, so I don't think we're running into skew across processes, but we do still have some error that isn't understood.

C 0.0001093917562557609

W 0.0000060596595090928 // Note: this error still isn't understood.

A 0.0000035446795473498

L 0.0000001223147062624

M 0.0000000052857133488

Mac doesn't have this issue nearly as often, but I don't think it's worth special casing for a single platform.

[Erik Chen]

Re: IsConsistentAcrossProcesses -- I believe this always returns true. The only implementation that has logic other than "return true" is on Windows. There's a giant comment there that claims that timestamps should be consistent post vista.

"""

  // According to Windows documentation [1] QPC is consistent post-Windows

  // Vista. So if we are using QPC then we are consistent which is the same as

  // being high resolution.

"""

> We thought Linux was the only issue, but Android and Chrome OS also provide bad timestamps. On certain Android devices, we see ~60% of event timestamps are obviously incorrect.

Fair enough. Thanks.

[Michael Spang]

Do you have any data on the Chrome OS issue? I thought we were providing good timestamps there.

Michael

--
You received this message because you are subscribed to the Google Groups "input-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to input-dev+...@chromium.org.

[Majid Valipour]

> I propose using the time at which input hits the browser process as the event timestamp as surfaced to JS, and as the base for all our input latency metrics. This will impact timestamps seen from JS.

This reduces our accuracy for well-behaved systems which according to our numbers are the vast majority. It seems that we should do the reverse which is to correct for the ill-behaved ones which should be rare. As long as we make sure the correction logic is cheap, it is a fairly robust solution.

Majid

  

[Tim Dresser]

Re Chrome OS Data: see the colab here. Some devices are definitely worse than others.

The problem is that we don't have a good way to distinguish between really broken cases and slightly broken cases. We can certainly correct timestamps which would result in negative durations, or timestamps which result in excessively large durations. However, we're likely to see some weird effects due to clamping excessively large durations. How do we pick what we mean by "excessively large"?

This does slightly reduce our accuracy, but historically, the delta between the hardware timestamp and hitting the browser thread has been tiny relative to overall event latency. We actually removed our metrics coverage of this because it was uninterestingly low and flat.

[Timothy Dresser]

Fixing domain mixing...

[Majid Valipour]

One thing that will be nice to see is if the fix you landed actually affects the unexpected timestamp rate you are seeing. This will confirm that the issue is indeed in platform provided timestamp.

BTW, devtools agents injected input can also be a  source for unexpected timestamp? Devtools protocol allows its client to inject input with arbitrary unix epoch timestamp. We do a best effort translation of that but it is a arbitrary time! Devtools agent is popular for test automation but I am not sure if it is actually problematic. The one example I look into was pupeteer which does not in fact send its own timestamp so it should be fine.

On Tue, Jul 24, 2018 at 1:13 PM Timothy Dresser <tdre...@chromium.org> wrote:

Fixing domain mixing...

On Tue, Jul 24, 2018 at 12:31 PM Tim Dresser <tdre...@google.com> wrote:

Re Chrome OS Data: see the colab here. Some devices are definitely worse than others.

The problem is that we don't have a good way to distinguish between really broken cases and slightly broken cases. We can certainly correct timestamps which would result in negative durations, or timestamps which result in excessively large durations. However, we're likely to see some weird effects due to clamping excessively large durations. How do we pick what we mean by "excessively large"?

So to summarize:

 Option A) Uniformly use browser timestamp for all input events

 Option B) Use hardware timestamp where it is "valid" but use browser timestamp otherwise.

BTW, on Linux where we have always had timestamp correction logic you are still seeing 0.00001%  of unexpected samples. So there are other factors at play it seems. And even with A in place the best you can get is this.

 

This does slightly reduce our accuracy, but historically, the delta between the hardware timestamp and hitting the browser thread has been tiny relative to overall event latency. We actually removed our metrics coverage of this because it was uninterestingly low and flat.

So if this is flat and low, it suggests a threshold based filter should work well without impacting your statistics. To be clear, I am suggesting that we look at the platform provided time when event is received on the browser and  ```t = abs(now - t) < THRESHOLD ? t : now```. 

Majid

[Timothy Dresser]

The uneven distribution across Android hardware classes is what makes me fairly confident that this is broken hardware timestamps.

I'm still collecting data on whether the fix I landed helps matters.

Devtools injected input is another possible source. We wouldn't expect it to be biased by hardware class though. Unless maybe there are specific hardware classes that folks only use for development? I'll dig into whether we're reporting synthetic events independently.

You're definitely right that there are other factors at play. 

I don't think your summary of the options is quite right. We can't actually tell the difference between valid and invalid timestamps. We can only guess, and we may introduce some strange biases when we believe a timestamp is valid, but it actually isn't.

I think that with the threshold based approach, we either:

• Make the threshold low enough that we make it impossible for us to ever see interesting data here. OR
• Make the threshold high enough that we see some skew from invalid event timestamps.

[Michael Spang]

Can you add device population to your table? The ones with very high error rates include some non-production ids such as "SORAKA TEST" that should be excluded.

You should be able to rely on the timestamps on Chrome OS because we deliver all of the software involved. I don't think it's likely that reading the clock from userspace will help. If things are sufficiently broken that reading the clock returns the wrong value, then it can't be fixed by chrome.

Michael

[Michael Spang]

On Tue, Jul 24, 2018 at 2:52 PM Timothy Dresser <tdre...@chromium.org> wrote:

The uneven distribution across Android hardware classes is what makes me fairly confident that this is broken hardware timestamps.

If you're getting 60% error rate on your "event age > 3 days" test on some Android device, that sounds like the timebase used by the system is not the one we expect.

Our assumption that we can compare to base::TimeTicks appears to be based on the AOSP implementation, not the Android API documentation or CTS.

The only thing we can do with Android input timestamps if we restrict ourselves to the documented behavior is to subtract them from one another and from the current time according to uptimeMillis().

Michael

 

--

[Timothy Dresser]

Thanks Michael, some good thoughts in there.
Filtering to exclude devices with very few samples does help some, but it still looks to me like there's a fair bit of device bias here. Much less than I was previously claiming though. I've updated the colab (Internal only)

The worst popular Chrome OS devices have ~40% of inputs being invalid, and the worst popular Android devices have just over 1% of inputs being invalid.

Hmmm, I wonder how much of the problem would go away if we took the event timestamp on Android to be:

base::TimeTicks() - (uptimeMillis() - eventTimestamp)

[Dave Tapuska]

Check out.. https://cs.chromium.org/chromium/src/base/time/time_android.cc?sq=package:chromium&g=0&l=10

You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-de...@chromium.org.
To post to this group, send email to schedu...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/scheduler-dev/CAHTsfZALqzQDLYaEjsfwTNgjY5hDKz-XP3YdseH5XHr7a-YGTQ%40mail.gmail.com.

[Michael Spang]

Thanks for updating the table.  I filed http://crbug.com/867696.  I'd bet the 3 hardware ids with bad data on Chrome OS are all related.

Michael

On Wed, Jul 25, 2018 at 9:43 AM Timothy Dresser <tdre...@chromium.org> wrote:

Ad

[Timothy Dresser]

Based on feedback, before making any decision here we'll:

• See how big an improvement the clamping patch provides.
• Disable reporting for synthetic input.
• Figure out what's happening on Chrome OS.

Tim

[Timothy Dresser]

We still have a non-trivial number of invalid reports on Android and it does appear to be more frequent on specific devices.

I think that for web developers, the benefits of switching to the browser timestamp outweighs the cost - I believe we stopped reporting the delta between the hardware and browser timestamps, because we never saw a regression in that value (with the exception of when we were tweaking how we handled event interpolation).

Even if we can filter invalid results out, it means we rely on web developers to do the same, which doesn't seem reasonable to me.

Does that make sense to folks?

[Michael Spang]

It does seem like on Chrome OS we had introduced a bug in the touchpad
timestamp generation, although Sean did not succeed in reproducing it.
Note that the new timestamp generation work was done to move things in
the opposite direction that you're proposing because the kernel
timestamps weren't good enough for velocity calculations for bluetooth
devices (see b/117569252). That speaks directly to the desire to have
the timestamp be the input sampling time as accurately as possible,
not some arbitrary later time on the CPU.

The primary purpose and intent of input timestamps is to provide the
timing of the input. It's about the physical event. Collecting
histograms that break down latencies in the event processing pipeline
is a secondary purpose.

On Chrome OS all input on the system passes through a ui::Event
including input that goes to the Android container. I would not be
happy if we were to discard the raw timestamp in all ui::Events on
that platform.









Michael

[tdre...@google.com]

Sorry, I didn't make a concrete proposal above.

I propose that we never surface the hardware timestamp to web developers, or downstream metrics consumers that aren't Chrome such as the Chrome User Experience Report.
I agree that we should continue collecting these for consumption by Chrome engineers.

Michael Spang wrote:

It does seem like on Chrome OS we had introduced a bug in the touchpad timestamp generation, although Sean did not succeed in reproducing it. Note that the new timestamp generation work was done to move things in the opposite direction that you're proposing because the kernel timestamps weren't good enough for velocity calculations for bluetooth devices (see b/117569252). That speaks directly to the desire to have the timestamp be the input sampling time as accurately as possible, not some arbitrary later time on the CPU. The primary purpose and intent of input timestamps is to provide the timing of the input. It's about the physical event. Collecting histograms that break down latencies in the event processing pipeline is a secondary purpose. On Chrome OS all input on the system passes through a ui::Event including input that goes to the Android container. I would not be happy if we were to discard the raw timestamp in all ui::Events on that platform. Michael On Thu, Feb 7, 2019 at 3:32 PM Timothy Dresser wrote: > > We still have a non-trivial number of invalid reports on Android and it does appear to be more frequent on specific devices. > > I think that for web developers, the benefits of switching to the browser timestamp outweighs the cost - I believe we stopped reporting the delta between the hardware and browser timestamps, because we never saw a regression in that value (with the exception of when we were tweaking how we handled event interpolation). > > Even if we can filter invalid results out, it means we rely on web developers to do the same, which doesn't seem reasonable to me. > > Does that make sense to folks? > > On Thu, Jul 26, 2018 at 10:13 AM Timothy Dresser wrote: >> >> Based on feedback, before making any decision here we'll: >> >> See how big an improvement the clamping patch provides. >> Disable reporting for synthetic input. >> Figure out what's happening on Chrome OS. >> >> Tim >> >> On Wed, Jul 25, 2018 at 7:50 PM Michael Spang wrote: >>> >>> Thanks for updating the table. I filed http://crbug.com/867696. I'd bet the 3 hardware ids with bad data on Chrome OS are all related. >>> >>> Michael >>> >>> On Wed, Jul 25, 2018 at 9:43 AM Timothy Dresser wrote: >>>> >>>> Thanks Michael, some good thoughts in there. >>>> Filtering to exclude devices with very few samples does help some, but it still looks to me like there's a fair bit of device bias here. Much less than I was previously claiming though. I've updated the colab (Internal only) >>>> >>>> The worst popular Chrome OS devices have ~40% of inputs being invalid, and the worst popular Android devices have just over 1% of inputs being invalid. >>>> >>>> Hmmm, I wonder how much of the problem would go away if we took the event timestamp on Android to be: >>>> base::TimeTicks() - (uptimeMillis() - eventTimestamp) >>>> >>>> On Tue, Jul 24, 2018 at 6:59 PM Michael Spang wrote: >>>>> >>>>> On Tue, Jul 24, 2018 at 2:52 PM Timothy Dresser wrote: >>>>>> >>>>>> The uneven distribution across Android hardware classes is what makes me fairly confident that this is broken hardware timestamps. >>>>> >>>>> >>>>> If you're getting 60% error rate on your "event age > 3 days" test on some Android device, that sounds like the timebase used by the system is not the one we expect. >>>>> >>>>> Our assumption that we can compare to base::TimeTicks appears to be based on the AOSP implementation, not the Android API documentation or CTS. >>>>> >>>>> The only thing we can do with Android input timestamps if we restrict ourselves to the documented behavior is to subtract them from one another and from the current time according to uptimeMillis(). >>>>> >>>>> Michael >>>>> >>>>>> >>>>>> >>>>>> I'm still collecting data on whether the fix I landed helps matters. >>>>>> >>>>>> Devtools injected input is another possible source. We wouldn't expect it to be biased by hardware class though. Unless maybe there are specific hardware classes that folks only use for development? I'll dig into whether we're reporting synthetic events independently. >>>>>> >>>>>> You're definitely right that there are other factors at play. >>>>>> >>>>>> I don't think your summary of the options is quite right. We can't actually tell the difference between valid and invalid timestamps. We can only guess, and we may introduce some strange biases when we believe a timestamp is valid, but it actually isn't. >>>>>> >>>>>> I think that with the threshold based approach, we either: >>>>>> >>>>>> Make the threshold low enough that we make it impossible for us to ever see interesting data here. OR >>>>>> Make the threshold high enough that we see some skew from invalid event timestamps. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jul 24, 2018 at 2:31 PM Majid Valipour wrote: >>>>>>> >>>>>>> One thing that will be nice to see is if the fix you landed actually affects the unexpected timestamp rate you are seeing. This will confirm that the issue is indeed in platform provided timestamp. >>>>>>> >>>>>>> BTW, devtools agents injected input can also be a source for unexpected timestamp? Devtools protocol allows its client to inject input with arbitrary unix epoch timestamp. We do a best effort translation of that but it is a arbitrary time! Devtools agent is popular for test automation but I am not sure if it is actually problematic. The one example I look into was pupeteer which does not in fact send its own timestamp so it should be fine. >>>>>>> >>>>>>> On Tue, Jul 24, 2018 at 1:13 PM Timothy Dresser wrote: >>>>>>>> >>>>>>>> Fixing domain mixing... >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Jul 24, 2018 at 12:31 PM Tim Dresser wrote: >>>>>>>>> >>>>>>>>> Re Chrome OS Data: see the colab here. Some devices are definitely worse than others. >>>>>>>>> >>>>>>>>> The problem is that we don't have a good way to distinguish between really broken cases and slightly broken cases. We can certainly correct timestamps which would result in negative durations, or timestamps which result in excessively large durations. However, we're likely to see some weird effects due to clamping excessively large durations. How do we pick what we mean by "excessively large"? >>>>>>> >>>>>>> >>>>>>> So to summarize: >>>>>>> Option A) Uniformly use browser timestamp for all input events >>>>>>> Option B) Use hardware timestamp where it is "valid" but use browser timestamp otherwise. >>>>>>> >>>>>>> BTW, on Linux where we have always had timestamp correction logic you are still seeing 0.00001% of unexpected samples. So there are other factors at play it seems. And even with A in place the best you can get is this. >>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> This does slightly reduce our accuracy, but historically, the delta between the hardware timestamp and hitting the browser thread has been tiny relative to overall event latency. We actually removed our metrics coverage of this because it was uninterestingly low and flat. >>>>>>> >>>>>>> >>>>>>> So if this is flat and low, it suggests a threshold based filter should work well without impacting your statistics. To be clear, I am suggesting that we look at the platform provided time when event is received on the browser and ```t = abs(now - t) < THRESHOLD ? t : now```. >>>>>>> >>>>>>> Majid >>>>>> >>>>>> -- >>>>>> >>>>>> You received this message because you are subscribed to the Google Groups "input-dev" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to input-dev+...@chromium.org. >>>>>> >>>>>> Ad > > -- > You received this message because you are subscribed to the Google Groups "input-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an email to input-dev+...@chromium.org.

[Michael Spang]

It makes sense to me that a report for web developers would not
include latencies web developers have no control over.

I'm less convinced about not exposing the timestamps at all. It
depends on what the web developers are trying to do, though, and how
buggy the native events are on the platform.

I assume you are not considering VR APIs in scope for the "no low
level timestamps" rule.



Michael

[Tim Dresser]

I was wrong about not having data for the delta. See: Event.Latency.OS.TOUCH_MOVED.

It's populated on Android and ChromeOS, though not Windows.

 On Android, the 99'th percentile is 23ms, and the 99.9th percentile is ~78ms. 
Compare that to overall latency, which is 99'th: 440ms, 99.9th: 3.6 seconds.

You're right that there may be cases where these numbers should be exposed to web devs - VR is a good example.
However, I think by default, we should expose the browser timestamp not the hardware timestamp.

[Tim Dresser]

Ping: input-dev folks, does this seem reasonable?

[Ella Ge]

Maybe off-topic, but I've seen some wrong timestamp on Android when show/hide the address bar. This is an example logging. 

[David Bokan]

I don't have much experience in the area so I just have some general questions:

- Do we have some expectations about what kind of changes/breakage this might cause to apps?

- Are web devs complaining about this or running into issues?

- Could we keep (internally) both hardware and browser time stamps, keep the hardware stamp exposed to the web but use the browser timestamp for metrics? This would make metrics more reliable but not mess with functionality that's working well where the stamps are reliable today.

[Timothy Dresser]

Breakage will be minor changes in metrics computed on the client. 

Web devs aren't complaining about this much, though I think there were a few anecdotes of folks being confused by crazy timestamps. Problems are infrequent enough that only large players are affected.

We should keep both timestamps around; however, for top level metrics, we try to measure the same thing in our metrics that is exposed to webdevs. Consistency here makes it easier to reason about our metrics holistically.

>> It does seem like on Chrome OS we had introduced a bug in the touchpad timestamp generation, although Sean did not succeed in reproducing it. Note that the new timestamp generation work was done to move things in the opposite direction that you're proposing because the kernel timestamps weren't good enough for velocity calculations for bluetooth devices (see b/117569252). That speaks directly to the desire to have the timestamp be the input sampling time as accurately as possible, not some arbitrary later time on the CPU. The primary purpose and intent of input timestamps is to provide the timing of the input. It's about the physical event. Collecting histograms that break down latencies in the event processing pipeline is a secondary purpose. On Chrome OS all input on the system passes through a ui::Event including input that goes to the Android container. I would not be happy if we were to discard the raw timestamp in all ui::Events on that platform. Michael On Thu, Feb 7, 2019 at 3:32 PM Timothy Dresser wrote: > > We still have a non-trivial number of invalid reports on Android and it does appear to be more frequent on specific devices. > > I think that for web developers, the benefits of switching to the browser timestamp outweighs the cost - I believe we stopped reporting the delta between the hardware and browser timestamps, because we never saw a regression in that value (with the exception of when we were tweaking how we handled event interpolation). > > Even if we can filter invalid results out, it means we rely on web developers to do the same, which doesn't seem reasonable to me. > > Does that make sense to folks? > > On Thu, Jul 26, 2018 at 10:13 AM Timothy Dresser wrote: >> >> Based on feedback, before making any decision here we'll: >> >> See how big an improvement the clamping patch provides. >> Disable reporting for synthetic input. >> Figure out what's happening on Chrome OS. >> >> Tim >> >> On Wed, Jul 25, 2018 at 7:50 PM Michael Spang wrote: >>> >>> Thanks for updating the table. I filed http://crbug.com/867696. I'd bet the 3 hardware ids with bad data on Chrome OS are all related. >>> >>> Michael >>> >>> On Wed, Jul 25, 2018 at 9:43 AM Timothy Dresser wrote: >>>> >>>> Thanks Michael, some good thoughts in there. >>>> Filtering to exclude devices with very few samples does help some, but it still looks to me like there's a fair bit of device bias here. Much less than I was previously claiming though. I've updated the colab (Internal only) >>>> >>>> The worst popular Chrome OS devices have ~40% of inputs being invalid, and the worst popular Android devices have just over 1% of inputs being invalid. >>>> >>>> Hmmm, I wonder how much of the problem would go away if we took the event timestamp on Android to be: >>>> base::TimeTicks() - (uptimeMillis() - eventTimestamp) >>>> >>>> On Tue, Jul 24, 2018 at 6:59 PM Michael Spang wrote: >>>>> >>>>> On Tue, Jul 24, 2018 at 2:52 PM Timothy Dresser wrote: >>>>>> >>>>>> The uneven distribution across Android hardware classes is what makes me fairly confident that this is broken hardware timestamps. >>>>> >>>>> >>>>> If you're getting 60% error rate on your "event age > 3 days" test on some Android device, that sounds like the timebase used by the system is not the one we expect. >>>>> >>>>> Our assumption that we can compare to base::TimeTicks appears to be based on the AOSP implementation, not the Android API documentation or CTS. >>>>> >>>>> The only thing we can do with Android input timestamps if we restrict ourselves to the documented behavior is to subtract them from one another and from the current time according to uptimeMillis(). >>>>> >>>>> Michael >>>>> >>>>>> >>>>>> >>>>>> I'm still collecting data on whether the fix I landed helps matters. >>>>>> >>>>>> Devtools injected input is another possible source. We wouldn't expect it to be biased by hardware class though. Unless maybe there are specific hardware classes that folks only use for development? I'll dig into whether we're reporting synthetic events independently. >>>>>> >>>>>> You're definitely right that there are other factors at play. >>>>>> >>>>>> I don't think your summary of the options is quite right. We can't actually tell the difference between valid and invalid timestamps. We can only guess, and we may introduce some strange biases when we believe a timestamp is valid, but it actually isn't. >>>>>> >>>>>> I think that with the threshold based approach, we either: >>>>>> >>>>>> Make the threshold low enough that we make it impossible for us to ever see interesting data here. OR >>>>>> Make the threshold high enough that we see some skew from invalid event timestamps. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jul 24, 2018 at 2:31 PM Majid Valipour wrote: >>>>>>> >>>>>>> One thing that will be nice to see is if the fix you landed actually affects the unexpected timestamp rate you are seeing. This will confirm that the issue is indeed in platform provided timestamp. >>>>>>> >>>>>>> BTW, devtools agents injected input can also be a source for unexpected timestamp? Devtools protocol allows its client to inject input with arbitrary unix epoch timestamp. We do a best effort translation of that but it is a arbitrary time! Devtools agent is popular for test automation but I am not sure if it is actually problematic. The one example I look into was pupeteer which does not in fact send its own timestamp so it should be fine. >>>>>>> >>>>>>> On Tue, Jul 24, 2018 at 1:13 PM Timothy Dresser wrote: >>>>>>>> >>>>>>>> Fixing domain mixing... >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Jul 24, 2018 at 12:31 PM Tim Dresser wrote: >>>>>>>>> >>>>>>>>> Re Chrome OS Data: see the colab here. Some devices are definitely worse than others. >>>>>>>>> >>>>>>>>> The problem is that we don't have a good way to distinguish between really broken cases and slightly broken cases. We can certainly correct timestamps which would result in negative durations, or timestamps which result in excessively large durations. However, we're likely to see some weird effects due to clamping excessively large durations. How do we pick what we mean by "excessively large"? >>>>>>> >>>>>>> >>>>>>> So to summarize: >>>>>>> Option A) Uniformly use browser timestamp for all input events >>>>>>> Option B) Use hardware timestamp where it is "valid" but use browser timestamp otherwise. >>>>>>> >>>>>>> BTW, on Linux where we have always had timestamp correction logic you are still seeing 0.00001% of unexpected samples. So there are other factors at play it seems. And even with A in place the best you can get is this. >>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> This does slightly reduce our accuracy, but historically, the delta between the hardware timestamp and hitting the browser thread has been tiny relative to overall event latency. We actually removed our metrics coverage of this because it was uninterestingly low and flat. >>>>>>> >>>>>>> >>>>>>> So if this is flat and low, it suggests a threshold based filter should work well without impacting your statistics. To be clear, I am suggesting that we look at the platform provided time when event is received on the browser and ```t = abs(now - t) < THRESHOLD ? t : now```. >>>>>>> >>>>>>> Majid >>>>>> >>>>>> -- >>>>>> >>>>>> You received this message because you are subscribed to the Google Groups "input-dev" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to input-dev+unsubscribe@chromium.org. >>>>>> >>>>>> Ad > > -- > You received this message because you are subscribed to the Google Groups "input-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an email to input-dev+unsubscribe@chromium.org.

>
> --
> You received this message because you are subscribed to the Google Groups "input-dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to input-dev+unsubscribe@chromium.org.

[xcode...@gmail.com]

在 2019年2月19日星期二 UTC+8下午10:49:36，Timothy Dresser写道：

> >> It does seem like on Chrome OS we had introduced a bug in the touchpad timestamp generation, although Sean did not succeed in reproducing it. Note that the new timestamp generation work was done to move things in the opposite direction that you're proposing because the kernel timestamps weren't good enough for velocity calculations for bluetooth devices (see b/117569252). That speaks directly to the desire to have the timestamp be the input sampling time as accurately as possible, not some arbitrary later time on the CPU. The primary purpose and intent of input timestamps is to provide the timing of the input. It's about the physical event. Collecting histograms that break down latencies in the event processing pipeline is a secondary purpose. On Chrome OS all input on the system passes through a ui::Event including input that goes to the Android container. I would not be happy if we were to discard the raw timestamp in all ui::Events on that platform. Michael On Thu, Feb 7, 2019 at 3:32 PM Timothy Dresser wrote: > > We still have a non-trivial number of invalid reports on Android and it does appear to be more frequent on specific devices. > > I think that for web developers, the benefits of switching to the browser timestamp outweighs the cost - I believe we stopped reporting the delta between the hardware and browser timestamps, because we never saw a regression in that value (with the exception of when we were tweaking how we handled event interpolation). > > Even if we can filter invalid results out, it means we rely on web developers to do the same, which doesn't seem reasonable to me. > > Does that make sense to folks? > > On Thu, Jul 26, 2018 at 10:13 AM Timothy Dresser wrote: >> >> Based on feedback, before making any decision here we'll: >> >> See how big an improvement the clamping patch provides. >> Disable reporting for synthetic input. >> Figure out what's happening on Chrome OS. >> >> Tim >> >> On Wed, Jul 25, 2018 at 7:50 PM Michael Spang wrote: >>> >>> Thanks for updating the table. I filed http://crbug.com/867696. I'd bet the 3 hardware ids with bad data on Chrome OS are all related. >>> >>> Michael >>> >>> On Wed, Jul 25, 2018 at 9:43 AM Timothy Dresser wrote: >>>> >>>> Thanks Michael, some good thoughts in there. >>>> Filtering to exclude devices with very few samples does help some, but it still looks to me like there's a fair bit of device bias here. Much less than I was previously claiming though. I've updated the colab (Internal only) >>>> >>>> The worst popular Chrome OS devices have ~40% of inputs being invalid, and the worst popular Android devices have just over 1% of inputs being invalid. >>>> >>>> Hmmm, I wonder how much of the problem would go away if we took the event timestamp on Android to be: >>>> base::TimeTicks() - (uptimeMillis() - eventTimestamp) >>>> >>>> On Tue, Jul 24, 2018 at 6:59 PM Michael Spang wrote: >>>>> >>>>> On Tue, Jul 24, 2018 at 2:52 PM Timothy Dresser wrote: >>>>>> >>>>>> The uneven distribution across Android hardware classes is what makes me fairly confident that this is broken hardware timestamps. >>>>> >>>>> >>>>> If you're getting 60% error rate on your "event age > 3 days" test on some Android device, that sounds like the timebase used by the system is not the one we expect. >>>>> >>>>> Our assumption that we can compare to base::TimeTicks appears to be based on the AOSP implementation, not the Android API documentation or CTS. >>>>> >>>>> The only thing we can do with Android input timestamps if we restrict ourselves to the documented behavior is to subtract them from one another and from the current time according to uptimeMillis(). >>>>> >>>>> Michael >>>>> >>>>>> >>>>>> >>>>>> I'm still collecting data on whether the fix I landed helps matters. >>>>>> >>>>>> Devtools injected input is another possible source. We wouldn't expect it to be biased by hardware class though. Unless maybe there are specific hardware classes that folks only use for development? I'll dig into whether we're reporting synthetic events independently. >>>>>> >>>>>> You're definitely right that there are other factors at play. >>>>>> >>>>>> I don't think your summary of the options is quite right. We can't actually tell the difference between valid and invalid timestamps. We can only guess, and we may introduce some strange biases when we believe a timestamp is valid, but it actually isn't. >>>>>> >>>>>> I think that with the threshold based approach, we either: >>>>>> >>>>>> Make the threshold low enough that we make it impossible for us to ever see interesting data here. OR >>>>>> Make the threshold high enough that we see some skew from invalid event timestamps. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jul 24, 2018 at 2:31 PM Majid Valipour wrote: >>>>>>> >>>>>>> One thing that will be nice to see is if the fix you landed actually affects the unexpected timestamp rate you are seeing. This will confirm that the issue is indeed in platform provided timestamp. >>>>>>> >>>>>>> BTW, devtools agents injected input can also be a source for unexpected timestamp? Devtools protocol allows its client to inject input with arbitrary unix epoch timestamp. We do a best effort translation of that but it is a arbitrary time! Devtools agent is popular for test automation but I am not sure if it is actually problematic. The one example I look into was pupeteer which does not in fact send its own timestamp so it should be fine. >>>>>>> >>>>>>> On Tue, Jul 24, 2018 at 1:13 PM Timothy Dresser wrote: >>>>>>>> >>>>>>>> Fixing domain mixing... >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Jul 24, 2018 at 12:31 PM Tim Dresser wrote: >>>>>>>>> >>>>>>>>> Re Chrome OS Data: see the colab here. Some devices are definitely worse than others. >>>>>>>>> >>>>>>>>> The problem is that we don't have a good way to distinguish between really broken cases and slightly broken cases. We can certainly correct timestamps which would result in negative durations, or timestamps which result in excessively large durations. However, we're likely to see some weird effects due to clamping excessively large durations. How do we pick what we mean by "excessively large"? >>>>>>> >>>>>>> >>>>>>> So to summarize: >>>>>>> Option A) Uniformly use browser timestamp for all input events >>>>>>> Option B) Use hardware timestamp where it is "valid" but use browser timestamp otherwise. >>>>>>> >>>>>>> BTW, on Linux where we have always had timestamp correction logic you are still seeing 0.00001% of unexpected samples. So there are other factors at play it seems. And even with A in place the best you can get is this. >>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> This does slightly reduce our accuracy, but historically, the delta between the hardware timestamp and hitting the browser thread has been tiny relative to overall event latency. We actually removed our metrics coverage of this because it was uninterestingly low and flat. >>>>>>> >>>>>>> >>>>>>> So if this is flat and low, it suggests a threshold based filter should work well without impacting your statistics. To be clear, I am suggesting that we look at the platform provided time when event is received on the browser and ```t = abs(now - t) < THRESHOLD ? t : now```. >>>>>>> >>>>>>> Majid >>>>>> >>>>>> -- >>>>>> >>>>>> You received this message because you are subscribed to the Google Groups "input-dev" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to inpu...@chromium.org. >>>>>> >>>>>> Ad > > -- > You received this message because you are subscribed to the Google Groups "input-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an email to inpu...@chromium.org.

>
> >
>
> > --
>
> > You received this message because you are subscribed to the Google Groups "input-dev" group.
>

> > To unsubscribe from this group and stop receiving emails from it, send an email to inpu...@chromium.org.

Is this issue related to https://bugs.chromium.org/p/chromium/issues/detail?id=976546 ?