On Wed, 2011-12-21 at 11:34 +0800, Daniel Kurtz wrote: > On Wed, Dec 21, 2011 at 10:23 AM, john stultz <johnstul@xxxxxxxxxx> wrote: > > On Wed, 2011-12-21 at 10:11 +0800, Daniel Kurtz wrote: > >> On Wed, Dec 21, 2011 at 9:41 AM, Wanlong Gao <gaowanlong@xxxxxxxxxxxxxx> wrote: > >> > On 12/21/2011 09:01 AM, john stultz wrote: > >> > > >> >> 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! > > > >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
