On Wed, Dec 21, 2011 at 3:53 PM, john stultz <johnstul@xxxxxxxxxx> wrote: > 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? Let's say a really bad clock is 1% slow. It will be off (relative to wallclock time) by 3 seconds every 5 minutes. Such a clock is really bad and will need frequent adjustments. * Those individual frequent clock adjustments, will probably happen in chunks on the order of several milliseconds. If such an adjustment happens between two input events, the resulting timestamp delta error is on the same order of magnitude as the timestamp delta itself, if not orders of magnitude larger. * However, when looking at inter-event arrival times, the affect of this huge clock skew is still only 1%. So a 10ms event arrival time will be off by 100 us. Even for this horrible clock, this is really very small. Real clocks have much less skew than this, however, the ntp clock adjustments would still be on the order of magnitude as the input event inter-arrival times, just much less frequent. But, the affect on an individual inter-event time is proportional to the skew. Sorry, I don't have real data to back this up, but this is my understanding of how it will work. Hopefully, I'm explaining it clearly enough to make my point. -Dan > 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 -- 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
