using monotonic clok for timstamping

using monotonic clok for timstamping

[Gregor Boirie]

Dear  all,

Our application relies on precise and monotonic timestamping of IMU 
samples (and other sensors).
I am wondering what reasons / use cases led to the choice of realtime 
clock to implement
iio_get_time_ns (not to mention time gaps that may be seen after wake up 
from sleep states).

As a dirty hack, I simply rewrote iio_get_time_ns on our platform. But I 
suspect it would be usefull as
a long term solution, to give userland the ability to choose a 
particular posix clock (realtime, monotonic,
etc...) on a per device and / or driver basis through a sysfs attribute 
for example.

I'd be glad to hear your suggestions. Best regards,
Grégor.

Re: using monotonic clok for timstamping

[Lars-Peter Clausen]

On 02/03/2016 11:55 AM, Gregor Boirie wrote:
> Dear  all,
> 
> Our application relies on precise and monotonic timestamping of IMU samples
> (and other sensors).
> I am wondering what reasons / use cases led to the choice of realtime clock
> to implement
> iio_get_time_ns (not to mention time gaps that may be seen after wake up
> from sleep states).

It's more of an oversight than a deliberate design decision. I noticed this
problem as well a while ago and wanted to re-write things to use the
monotonic clock, but then realized that this would be a ABI change so
dropped it and forgot about it again.

> 
> As a dirty hack, I simply rewrote iio_get_time_ns on our platform. But I
> suspect it would be usefull as
> a long term solution, to give userland the ability to choose a particular
> posix clock (realtime, monotonic,
> etc...) on a per device and / or driver basis through a sysfs attribute for
> example.

This is probably the only viable solution while keeping the ABI backwards
compatible.

- Lars

Re: using monotonic clok for timstamping

[Jonathan Cameron]

On 03/02/16 11:22, Lars-Peter Clausen wrote:
> On 02/03/2016 11:55 AM, Gregor Boirie wrote:
>> Dear  all,
>>
>> Our application relies on precise and monotonic timestamping of IMU samples
>> (and other sensors).
>> I am wondering what reasons / use cases led to the choice of realtime clock
>> to implement
>> iio_get_time_ns (not to mention time gaps that may be seen after wake up
>> from sleep states).
> 
> It's more of an oversight than a deliberate design decision. I noticed this
> problem as well a while ago and wanted to re-write things to use the
> monotonic clock, but then realized that this would be a ABI change so
> dropped it and forgot about it again.
There are certainly cases where the other clock would make sense (for slow
sampling device where being as correct as possible is the most important
thing).

However as Lars observed it was as well considered a choice as it should have
been as this dates back all the way.
> 
>>
>> As a dirty hack, I simply rewrote iio_get_time_ns on our platform. But I
>> suspect it would be usefull as
>> a long term solution, to give userland the ability to choose a particular
>> posix clock (realtime, monotonic,
>> etc...) on a per device and / or driver basis through a sysfs attribute for
>> example.
> 
> This is probably the only viable solution while keeping the ABI backwards
> compatible.
Agreed - preference for per device instance sysfs attribute.
If it were just the buffered timestamp readings, we could make it an attribute
for that single channel, but timestamps are also used with events and we
would therefore probably want it to be consistent for a whole instance of the
device.

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

Re: using monotonic clok for timstamping

[Lars-Peter Clausen]

On 02/06/2016 07:33 PM, Jonathan Cameron wrote:
> On 03/02/16 11:22, Lars-Peter Clausen wrote:
>> On 02/03/2016 11:55 AM, Gregor Boirie wrote:
>>> Dear  all,
>>>
>>> Our application relies on precise and monotonic timestamping of IMU samples
>>> (and other sensors).
>>> I am wondering what reasons / use cases led to the choice of realtime clock
>>> to implement
>>> iio_get_time_ns (not to mention time gaps that may be seen after wake up
>>> from sleep states).
>>
>> It's more of an oversight than a deliberate design decision. I noticed this
>> problem as well a while ago and wanted to re-write things to use the
>> monotonic clock, but then realized that this would be a ABI change so
>> dropped it and forgot about it again.
> There are certainly cases where the other clock would make sense (for slow
> sampling device where being as correct as possible is the most important
> thing).

I'm not sure I understand what you are trying to say, maybe we are not on
the same page. As far as I know both clocks have the same precession, but
their absolute value differs.

What iio_get_time_ns() currently returns is the system clock, which changes
whenever the time is changed (e.g. to compensate for drift, or daylight
saving, etc.). This is obviously not so great if that happens in the middle
of the capture since what you care about is the relative distance between
the samples and if your time base changes you have no idea what that is anymore.

So the monotonic clock which just keeps going at a fixed interval would be
the better choice.

Re: using monotonic clok for timstamping

[Jonathan Cameron]

On 8 February 2016 09:55:08 GMT+00:00, Lars-Peter Clausen <lars@metafoo.de> wrote:
>On 02/06/2016 07:33 PM, Jonathan Cameron wrote:
>> On 03/02/16 11:22, Lars-Peter Clausen wrote:
>>> On 02/03/2016 11:55 AM, Gregor Boirie wrote:
>>>> Dear  all,
>>>>
>>>> Our application relies on precise and monotonic timestamping of IMU
>samples
>>>> (and other sensors).
>>>> I am wondering what reasons / use cases led to the choice of
>realtime clock
>>>> to implement
>>>> iio_get_time_ns (not to mention time gaps that may be seen after
>wake up
>>>> from sleep states).
>>>
>>> It's more of an oversight than a deliberate design decision. I
>noticed this
>>> problem as well a while ago and wanted to re-write things to use the
>>> monotonic clock, but then realized that this would be a ABI change
>so
>>> dropped it and forgot about it again.
>> There are certainly cases where the other clock would make sense (for
>slow
>> sampling device where being as correct as possible is the most
>important
>> thing).
>
>I'm not sure I understand what you are trying to say, maybe we are not
>on
>the same page. As far as I know both clocks have the same precession,
>but
>their absolute value differs.
>
>What iio_get_time_ns() currently returns is the system clock, which
>changes
>whenever the time is changed (e.g. to compensate for drift, or daylight
>saving, etc.). This is obviously not so great if that happens in the
>middle
>of the capture since what you care about is the relative distance
>between
>the samples and if your time base changes you have no idea what that is
>anymore.
>
>So the monotonic clock which just keeps going at a fixed interval would
>be
>the better choice.

In general I agree. My thought was that there are plausible usecases where a
 capture is every n minutes over days or years where a timestamp that tracks with
 'corrections' would make sense as intervals are not always the most
 important thing.

Most cases if course the monotonic clock is the best one. I chose badly a long time ago! Risk is someone is relying on it for some reason.

J

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: using monotonic clok for timstamping

[Gregor Boirie]

To sump up, implementing timestamping clock selection support in IIO
should be based on the following principles.

Selected timestamping clock is a per-device attribute which the userspace
may access through a sysfs file.

It must be applicable to both buffered samples and events.

Userspace may choose amongst a subset of available POSIX clocks. A good
starting point would be: CLOCK_REALTIME, CLOCK_MONOTONIC,
CLOCK_MONOTONIC_RAW, CLOCK_REALTIME_COARSE,
CLOCK_MONOTONIC_COARSE, CLOCK_BOOTTIME and CLOCK_TAI.
Please delete as appropriate if needed and see clock_gettime(2).

One remaining question is : how do we ensure sample and event timestamps
consistency with respect to clock changes ? 2 suggestions:
* reject the ability to select a new clock as long as an events chardev 
is opened
   or a buffered samples channel is enabled ;
* clock may be changed at any time since it could be implemented in an 
atomic
   way (a simple atomic_t can hold an int / clockid_t if I'm no wrong).

Regards.

On 02/08/2016 06:15 PM, Jonathan Cameron wrote:
>
> On 8 February 2016 09:55:08 GMT+00:00, Lars-Peter Clausen <lars@metafoo.de> wrote:
>> On 02/06/2016 07:33 PM, Jonathan Cameron wrote:
>>> On 03/02/16 11:22, Lars-Peter Clausen wrote:
>>>> On 02/03/2016 11:55 AM, Gregor Boirie wrote:
>>>>> Dear  all,
>>>>>
>>>>> Our application relies on precise and monotonic timestamping of IMU
>> samples
>>>>> (and other sensors).
>>>>> I am wondering what reasons / use cases led to the choice of
>> realtime clock
>>>>> to implement
>>>>> iio_get_time_ns (not to mention time gaps that may be seen after
>> wake up
>>>>> from sleep states).
>>>> It's more of an oversight than a deliberate design decision. I
>> noticed this
>>>> problem as well a while ago and wanted to re-write things to use the
>>>> monotonic clock, but then realized that this would be a ABI change
>> so
>>>> dropped it and forgot about it again.
>>> There are certainly cases where the other clock would make sense (for
>> slow
>>> sampling device where being as correct as possible is the most
>> important
>>> thing).
>> I'm not sure I understand what you are trying to say, maybe we are not
>> on
>> the same page. As far as I know both clocks have the same precession,
>> but
>> their absolute value differs.
>>
>> What iio_get_time_ns() currently returns is the system clock, which
>> changes
>> whenever the time is changed (e.g. to compensate for drift, or daylight
>> saving, etc.). This is obviously not so great if that happens in the
>> middle
>> of the capture since what you care about is the relative distance
>> between
>> the samples and if your time base changes you have no idea what that is
>> anymore.
>>
>> So the monotonic clock which just keeps going at a fixed interval would
>> be
>> the better choice.
> In general I agree. My thought was that there are plausible usecases where a
>   capture is every n minutes over days or years where a timestamp that tracks with
>   'corrections' would make sense as intervals are not always the most
>   important thing.
>
> Most cases if course the monotonic clock is the best one. I chose badly a long time ago! Risk is someone is relying on it for some reason.
>
> J
>

Re: using monotonic clok for timstamping

[Gregor Boirie]

On 02/09/2016 12:06 PM, Gregor Boirie wrote:
> One remaining question is : how do we ensure sample and event timestamps
> consistency with respect to clock changes ? 2 suggestions:
> * reject the ability to select a new clock as long as an events 
> chardev is opened
>   or a buffered samples channel is enabled ;
Actually, this may be the only viable solution since some drivers save 
timestamps for
futur usage (see drivers/iio/accel/bmc150-accel-core.c). Changing 
reference clock
between 2 timestamping operations would lead to inconsistencies.

> * clock may be changed at any time since it could be implemented in an 
> atomic
>   way (a simple atomic_t can hold an int / clockid_t if I'm no wrong).

Re: using monotonic clok for timstamping

[Jonathan Cameron]

On 09/02/16 14:19, Gregor Boirie wrote:
> On 02/09/2016 12:06 PM, Gregor Boirie wrote:
>> One remaining question is : how do we ensure sample and event timestamps
>> consistency with respect to clock changes ? 2 suggestions:
>> * reject the ability to select a new clock as long as an events chardev is opened
>>   or a buffered samples channel is enabled ;
> Actually, this may be the only viable solution since some drivers save timestamps for
> futur usage (see drivers/iio/accel/bmc150-accel-core.c). Changing reference clock
> between 2 timestamping operations would lead to inconsistencies.
Agreed.  It will want to be locked unless we can be fairly sure it's not in use.
In most cases I can't see why a user wouldn't set it before opening any of the chardevs
so that would cover the direct userspace access case.  The more complex option is in
kernel use of the buffered interface (or events once I we actually add an interface
to get those in client drivers).  As you say, locking when the channel is enabled
would work - or during the buffer set up and unlock in the tear down.  Hold
mlock when updating as well to prevent any odd windows of buffer going up or coming down.

Should work I think.... Though the proof as ever will be in the code!

Jonathan
>> * clock may be changed at any time since it could be implemented in an atomic
>>   way (a simple atomic_t can hold an int / clockid_t if I'm no wrong).
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: using monotonic clok for timstamping

[Lars-Peter Clausen]

On 02/09/2016 12:06 PM, Gregor Boirie wrote:
> To sump up, implementing timestamping clock selection support in IIO
> should be based on the following principles.
> 
> Selected timestamping clock is a per-device attribute which the userspace
> may access through a sysfs file.
> 
> It must be applicable to both buffered samples and events.

Just playing out ideas here to make sure we have everything covered, but
could be there be a setup where you'd want different timestamps for events
and buffers?

> 
> Userspace may choose amongst a subset of available POSIX clocks. A good
> starting point would be: CLOCK_REALTIME, CLOCK_MONOTONIC,
> CLOCK_MONOTONIC_RAW, CLOCK_REALTIME_COARSE,
> CLOCK_MONOTONIC_COARSE, CLOCK_BOOTTIME and CLOCK_TAI.
> Please delete as appropriate if needed and see clock_gettime(2).
> 
> One remaining question is : how do we ensure sample and event timestamps
> consistency with respect to clock changes ? 2 suggestions:
> * reject the ability to select a new clock as long as an events chardev is
> opened
>   or a buffered samples channel is enabled ;
> * clock may be changed at any time since it could be implemented in an atomic
>   way (a simple atomic_t can hold an int / clockid_t if I'm no wrong).

Not sure if we need to prevent it. If somebody changes it during an active
measurement it is their problem I'd say.

Re: using monotonic clok for timstamping

[Jonathan Cameron]

On 09/02/16 20:52, Lars-Peter Clausen wrote:
> On 02/09/2016 12:06 PM, Gregor Boirie wrote:
>> To sump up, implementing timestamping clock selection support in IIO
>> should be based on the following principles.
>>
>> Selected timestamping clock is a per-device attribute which the userspace
>> may access through a sysfs file.
>>
>> It must be applicable to both buffered samples and events.
> 
> Just playing out ideas here to make sure we have everything covered, but
> could be there be a setup where you'd want different timestamps for events
> and buffers?
I hope not..
> 
>>
>> Userspace may choose amongst a subset of available POSIX clocks. A good
>> starting point would be: CLOCK_REALTIME, CLOCK_MONOTONIC,
>> CLOCK_MONOTONIC_RAW, CLOCK_REALTIME_COARSE,
>> CLOCK_MONOTONIC_COARSE, CLOCK_BOOTTIME and CLOCK_TAI.
>> Please delete as appropriate if needed and see clock_gettime(2).
>>
>> One remaining question is : how do we ensure sample and event timestamps
>> consistency with respect to clock changes ? 2 suggestions:
>> * reject the ability to select a new clock as long as an events chardev is
>> opened
>>   or a buffered samples channel is enabled ;
>> * clock may be changed at any time since it could be implemented in an atomic
>>   way (a simple atomic_t can hold an int / clockid_t if I'm no wrong).
> 
> Not sure if we need to prevent it. If somebody changes it during an active
> measurement it is their problem I'd say.
A fair point if we document it clearly as 'HERE BE DRAGONS!'
Won't typically crash anything, just give crazy answers :)
> 

Re: using monotonic clok for timstamping

[Gregor Boirie]

On 02/09/2016 09:52 PM, Lars-Peter Clausen wrote:
> On 02/09/2016 12:06 PM, Gregor Boirie wrote:
>> To sump up, implementing timestamping clock selection support in IIO
>> should be based on the following principles.
>>
>> Selected timestamping clock is a per-device attribute which the userspace
>> may access through a sysfs file.
>>
>> It must be applicable to both buffered samples and events.
> Just playing out ideas here to make sure we have everything covered, but
> could be there be a setup where you'd want different timestamps for events
> and buffers?
I'm not familiar enough with events to tell.

>> Userspace may choose amongst a subset of available POSIX clocks. A good
>> starting point would be: CLOCK_REALTIME, CLOCK_MONOTONIC,
>> CLOCK_MONOTONIC_RAW, CLOCK_REALTIME_COARSE,
>> CLOCK_MONOTONIC_COARSE, CLOCK_BOOTTIME and CLOCK_TAI.
>> Please delete as appropriate if needed and see clock_gettime(2).
>>
>> One remaining question is : how do we ensure sample and event timestamps
>> consistency with respect to clock changes ? 2 suggestions:
>> * reject the ability to select a new clock as long as an events chardev is
>> opened
>>    or a buffered samples channel is enabled ;
>> * clock may be changed at any time since it could be implemented in an atomic
>>    way (a simple atomic_t can hold an int / clockid_t if I'm no wrong).
> Not sure if we need to prevent it. If somebody changes it during an active
> measurement it is their problem I'd say.
I like this way of keeping it simple. However, wouldn't this make the API
inhomogeneous ? After all, many channel related operations return
-EBUSY while flowing samples...