Re: [RFC] Monotonic clock usage in buffer timestamps

["Daniel Glöckner" <daniel-gl@gmx.net>]

On Wed, Nov 02, 2011 at 12:14:49PM +0200, Sakari Ailus wrote:
> > How about making all drivers record monotonic timestamps and doing
> > the conversion to/from realtime timestamps in v4l2-ioctl.c's
> > __video_do_ioctl if requested? We then just need an extension of the
> > spec to switch to monotonic, which can be implemented without touching
> > a single driver.
> 
> Converting between the two can be done when making the timestamp but it's
> non-trivial at other times and likely isn't supported. I could be wrong,
> though. This might lead to e.g. timestamps that are taken before switching
> to summer time and for which the conversion is done after the switch. This
> might be a theoretical possibility, but there might be also unfavourable
> interaction with the NTP.

Summertime/wintertime is purely a userspace thing. UTC as returned by
gettimeofday is unaffected by that.

NTP AFAIK adjusts the speed of the monotonic clock, so there is a constant
delta between wall clock time and clock monotonic unless there is a leap
second or someone calls settimeofday. Applications currently using the
wall clock timestamps should have trouble dealing with that as well.

> I'd probably rather just make a new timestamp in wall clock time in
> v4l2-ioctl.c if needed using do_gettimeofday().

I think that would be worse than subtracting ktime_get_monotonic_offset().
You don't know the delay between capturing a frame and calling dqbuf.

If there is a settimeofday between capturing a frame and calling dqbuf,
the wall time clock was probably wrong when the frame was captured
and subtracting the new ktime_get_monotonic_offset() yields a better
timestamp.

> Or just do the wall clock timestamps user space as they are typically
> critical in timing.
>
> How would this work for you?

As I keep the cpu busy with video encoding in the same thread, I'd expect
a high jitter from taking timestamps in userspace.

  Daniel