using monotonic clok for timstamping
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.
Quoted 8 lines · 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 implementiio_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.
Quoted 7 lines
As a dirty hack, I simply rewrote
iio_get_time_nson 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
Jonathan Cameron
maintainerQuoted 10 lines · Lars-Peter Clausen
Quoted 8 lines · 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 implementiio_get_time_ns(not to mention time gaps that may be seen after wake up from sleep states).
Quoted 4 lines
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.
Quoted 11 lines
Quoted 8 lines
As a dirty hack, I simply rewrote
iio_get_time_nson 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
Quoted 8 lines
- Lars
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 11 lines · Jonathan Cameron
Quoted 10 lines · Lars-Peter Clausen
Quoted 8 lines · 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 implementiio_get_time_ns(not to mention time gaps that may be seen after wake up from sleep states).
Quoted 7 lines
Quoted 4 lines
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.
Quoted 43 lines · Lars-Peter Clausen
Quoted 5 lines · Jonathan Cameron
Quoted 4 lines · Lars-Peter Clausen
Quoted 3 lines · Gregor Boirie
Dear all,
Our application relies on precise and monotonic timestamping of IMU
samples
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
(and other sensors).
I am wondering what reasons / use cases led to the choice ofrealtime clock
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
to implement
iio_get_time_ns(not to mention time gaps that may be seen afterwake up
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
from sleep states).
It's more of an oversight than a deliberate design decision. I
noticed this
Quoted 2 lines
Quoted 2 lines
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
Quoted 2 lines
Quoted 1 line
dropped it and forgot about it again.
There are certainly cases where the other clock would make sense (for
slow
Quoted 1 line
sampling device where being as correct as possible is the most
important
Quoted 1 line
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.
Quoted 3 lines
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
Signature · 1 line
Sent from my Android device with K-9 Mail. Please excuse my brevity.
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.
Quoted 55 lines · Jonathan Cameron
Quoted 41 lines · Lars-Peter Clausen
Quoted 5 lines · Jonathan Cameron
Quoted 4 lines · Lars-Peter Clausen
Quoted 3 lines · Gregor Boirie
Dear all,
Our application relies on precise and monotonic timestamping of IMU
samples
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
(and other sensors).
I am wondering what reasons / use cases led to the choice ofrealtime clock
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
to implement
iio_get_time_ns(not to mention time gaps that may be seen afterwake up
Quoted 2 lines
Quoted 2 lines
Quoted 1 line
from sleep states).
It's more of an oversight than a deliberate design decision. I
noticed this
Quoted 2 lines
Quoted 2 lines
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
Quoted 2 lines
Quoted 1 line
dropped it and forgot about it again.
There are certainly cases where the other clock would make sense (for
slow
Quoted 1 line
sampling device where being as correct as possible is the most
important
Quoted 1 line
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.Quoted 3 lines
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
Quoted 4 lines · Gregor Boirie
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.
Quoted 2 lines
* clock may be changed at any time since it could be implemented in an atomic way (a simple
atomic_tcan hold an int /clockid_tif I'm no wrong).
Jonathan Cameron
maintainerQuoted 8 lines · Gregor Boirie
Quoted 4 lines · Gregor Boirie
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
Quoted 6 lines
Quoted 2 lines
* clock may be changed at any time since it could be implemented in an atomic way (a simple
atomic_tcan hold an int /clockid_tif I'm no wrong).Signature · 3 lines
To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 7 lines · 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.
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?
Quoted 7 lines
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_BOOTTIMEandCLOCK_TAI.
Please delete as appropriate if needed and seeclock_gettime(2).
Quoted 7 lines
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 simpleatomic_tcan hold an int /clockid_tif 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.
Jonathan Cameron
maintainerQuoted 4 lines · Lars-Peter Clausen
Quoted 3 lines · Gregor Boirie
To sump up, implementing timestamping clock selection support in IIO should be based on the following principles.
Quoted 8 lines
Quoted 4 lines
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..
Quoted 16 lines
Quoted 8 lines
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_BOOTTIMEandCLOCK_TAI.
Please delete as appropriate if needed and seeclock_gettime(2).Quoted 7 lines
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 simpleatomic_tcan hold an int /clockid_tif I'm no wrong).
Quoted 2 lines
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 :)
Quoted 1 line
Quoted 11 lines · Lars-Peter Clausen
Quoted 7 lines · 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.
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.
Quoted 13 lines
Quoted 6 lines
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_BOOTTIMEandCLOCK_TAI.
Please delete as appropriate if needed and seeclock_gettime(2).Quoted 7 lines
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 simpleatomic_tcan hold an int /clockid_tif I'm no wrong).
Quoted 2 lines
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...