All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Lars-Peter Clausen <lars@metafoo.de>,
	Gregor Boirie <gregor.boirie@parrot.com>,
	linux-iio@vger.kernel.org
Subject: Re: using monotonic clok for timstamping
Date: Sat, 6 Feb 2016 18:33:50 +0000	[thread overview]
Message-ID: <56B63C8E.3020309@kernel.org> (raw)
In-Reply-To: <56B1E2D8.90308@metafoo.de>

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
> 


  reply	other threads:[~2016-02-06 18:33 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-03 10:55 using monotonic clok for timstamping Gregor Boirie
2016-02-03 11:22 ` Lars-Peter Clausen
2016-02-06 18:33   ` Jonathan Cameron [this message]
2016-02-08  9:55     ` Lars-Peter Clausen
2016-02-08 17:15       ` Jonathan Cameron
2016-02-09 11:06         ` Gregor Boirie
2016-02-09 14:19           ` Gregor Boirie
2016-02-09 20:49             ` Jonathan Cameron
2016-02-09 20:52           ` Lars-Peter Clausen
2016-02-09 21:02             ` Jonathan Cameron
2016-02-10  9:46             ` Gregor Boirie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56B63C8E.3020309@kernel.org \
    --to=jic23@kernel.org \
    --cc=gregor.boirie@parrot.com \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.