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

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

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)?

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.

-Dan

thanks
-john


--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html