Re: [RFC][PATCH] Input: Use monotonic time for event time stamps.

On Wed, 2011-12-21 at 11:34 +0800, Daniel Kurtz wrote:

On Wed, Dec 21, 2011 at 10:23 AM, john stultz [off-list ref] wrote:

quoted

On Wed, 2011-12-21 at 10:11 +0800, Daniel Kurtz wrote:

quoted

On Wed, Dec 21, 2011 at 9:41 AM, Wanlong Gao [off-list ref] wrote:

quoted

On 12/21/2011 09:01 AM, john stultz wrote:

quoted

Hi
      In reviewing the Android patch set, I noticed the following patch from
Arve which looks like it resolves a reasonable issue (events using
CLOCK_REALTIME timestamps, which can jump forwards or backwards via
settimeofday()).

I'm not very familiar with the evdev interface, so I'm not sure if
changing the timestamps to CLOCK_MONOTONIC could cause an ABI problem
with legacy apps. Even so, I wanted to send the patch out for review and
consideration as it seems like a reasonable fix.

Maybe you will have more luck this time.  You can read the previous
thread on this exact topic, here:
https://lkml.org/lkml/2011/10/3/37

Interesting! Thanks for the link!

quoted

The previous attempt got bogged down when people wanted more data on
use cases and how this patch would promote world peace.  I strongly
support the concept, but we found other ways to address our major
concern at the time, so didn't invest more effort to get that patch
accepted.

Just a question though, why ktime_get_ts() and not getrawmonotonic()?

So rawmonotonic isn't frequency corrected via NTP, while the monotonic
clock is. So if you're calculating intervals, you will get more accurate
times (where a second is a second) w/ ktime_get_ts().

The raw monotonic clock is really only useful for time correction
applications (being able to accurately measure how much of a correction
was applied), or when you really want a abstracted sense of hardware
cycles.

And here is where it gets complicated.  I think it depends on what you
want from your timestamps.

Do you care that the actual timestamps are accurate (wrt wall clock =
MONOTONIC), or that inter-event timetamp spacing is consistent
(MONOTONIC_RAW)?

Although, hardware fluctuates as well (I've watched clock skew along
with AC cycles). So neither is surely to be totally consistent.

For our use case, we don't really care about the absolute timestamp
itself, just relative timestamp differences.  We wanted to make sure
that the inter-event times were always consistent, and didn't wobble
about in response to cock adjustments.  The affect of clock skew on
timestamp deltas is miniscule.

Hrm. I'm curious. If clock skew is miniscule, any correction should be
as well. Have you seen actual issues with clock freq correction here
that necessitated using the raw-monotonic clock? Any details if so?

thanks
-john