All of lore.kernel.org
 help / color / mirror / Atom feed
* fxls8962af: RTC and NTP
@ 2023-01-09  7:54 Sean Nyekjaer
  2023-01-09 15:39 ` Jonathan Cameron
  0 siblings, 1 reply; 3+ messages in thread
From: Sean Nyekjaer @ 2023-01-09  7:54 UTC (permalink / raw)
  To: linux-iio, Jonathan Cameron

Hi Jonathan and list,

We are getting some weird timestamps (with fxls8962af) in the iio 
buffers when time is set back by NTP.

Here I have dumped old_timestamp, timestamp from the 
fxls8962af_fifo_flush():
old_timestamp 1673008488434717043, timestamp 1673008489457042043
*old_timestamp 1673008489457042043, timestamp 1673008485198504719*
old_timestamp 1673008485198504719, timestamp 1673008486220571510

Time is set back in the middle data set, so the sample timestamp looks like:
tstamp0 3091988802491735451
tstamp1 4510969115526428858
tstamp2 5929949428561122265
tstamp3 7348929741595815672
tstamp4 8767910054630509079
tstamp5 -8259853706044349130
tstamp6 -6840873393009655723
tstamp7 -5421893079974962316
tstamp8 -4002912766940268909
tstamp9 -2583932453905575502
tstamp10 -1164952140870882095
tstamp11 254028172163811312
tstamp12 1673008485198504719

Possible solutions?
Could we store the sample time from the last collected data set?
And use that if old_timestamp > timestamp?

Or do you have any other idea's?

/Sean

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: fxls8962af: RTC and NTP
  2023-01-09  7:54 fxls8962af: RTC and NTP Sean Nyekjaer
@ 2023-01-09 15:39 ` Jonathan Cameron
  2023-01-10 13:26   ` Sean Nyekjaer
  0 siblings, 1 reply; 3+ messages in thread
From: Jonathan Cameron @ 2023-01-09 15:39 UTC (permalink / raw)
  To: Sean Nyekjaer; +Cc: linux-iio, Jonathan Cameron

On Mon, 9 Jan 2023 08:54:05 +0100
Sean Nyekjaer <sean@geanix.com> wrote:

> Hi Jonathan and list,
> 
> We are getting some weird timestamps (with fxls8962af) in the iio 
> buffers when time is set back by NTP.
> 
> Here I have dumped old_timestamp, timestamp from the 
> fxls8962af_fifo_flush():
> old_timestamp 1673008488434717043, timestamp 1673008489457042043
> *old_timestamp 1673008489457042043, timestamp 1673008485198504719*
> old_timestamp 1673008485198504719, timestamp 1673008486220571510
> 
> Time is set back in the middle data set, so the sample timestamp looks like:
> tstamp0 3091988802491735451
> tstamp1 4510969115526428858
> tstamp2 5929949428561122265
> tstamp3 7348929741595815672
> tstamp4 8767910054630509079
> tstamp5 -8259853706044349130
> tstamp6 -6840873393009655723
> tstamp7 -5421893079974962316
> tstamp8 -4002912766940268909
> tstamp9 -2583932453905575502
> tstamp10 -1164952140870882095
> tstamp11 254028172163811312
> tstamp12 1673008485198504719
> 
> Possible solutions?
> Could we store the sample time from the last collected data set?
> And use that if old_timestamp > timestamp?

Ah. I guess this is the timestamp interpolation code going wrong.
It should be possible to make that code 'sort of cope' with negatives
though it would be a slightly nasty heuristic.
You would make it go backwards a little for each fifo entry..

> 
> Or do you have any other idea's?

This mess is a side effect of me picking a silly default clock
a long time back (can't fix that as it's ABI...)

We could smooth it in the driver, but if you have
the option, I'd just change the default clock from userspace.
Take a look at current_timestamp_clock in sysfs.
You should be fine with "monotonic" 

> 
> /Sean


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: fxls8962af: RTC and NTP
  2023-01-09 15:39 ` Jonathan Cameron
@ 2023-01-10 13:26   ` Sean Nyekjaer
  0 siblings, 0 replies; 3+ messages in thread
From: Sean Nyekjaer @ 2023-01-10 13:26 UTC (permalink / raw)
  To: Jonathan Cameron; +Cc: linux-iio, Jonathan Cameron



On 09/01/2023 16.39, Jonathan Cameron wrote:
> On Mon, 9 Jan 2023 08:54:05 +0100
> Sean Nyekjaer <sean@geanix.com> wrote:
> 
>> Hi Jonathan and list,
>>
>> We are getting some weird timestamps (with fxls8962af) in the iio
>> buffers when time is set back by NTP.
>>
>> Here I have dumped old_timestamp, timestamp from the
>> fxls8962af_fifo_flush():
>> old_timestamp 1673008488434717043, timestamp 1673008489457042043
>> *old_timestamp 1673008489457042043, timestamp 1673008485198504719*
>> old_timestamp 1673008485198504719, timestamp 1673008486220571510
>>
>> Time is set back in the middle data set, so the sample timestamp looks like:
>> tstamp0 3091988802491735451
>> tstamp1 4510969115526428858
>> tstamp2 5929949428561122265
>> tstamp3 7348929741595815672
>> tstamp4 8767910054630509079
>> tstamp5 -8259853706044349130
>> tstamp6 -6840873393009655723
>> tstamp7 -5421893079974962316
>> tstamp8 -4002912766940268909
>> tstamp9 -2583932453905575502
>> tstamp10 -1164952140870882095
>> tstamp11 254028172163811312
>> tstamp12 1673008485198504719
>>
>> Possible solutions?
>> Could we store the sample time from the last collected data set?
>> And use that if old_timestamp > timestamp?
> 
> Ah. I guess this is the timestamp interpolation code going wrong.
> It should be possible to make that code 'sort of cope' with negatives
> though it would be a slightly nasty heuristic.
> You would make it go backwards a little for each fifo entry..
> 

Yeah agree, but then you could have 2 (or 3) samples with the same 
timestamp :/

>>
>> Or do you have any other idea's?
> 
> This mess is a side effect of me picking a silly default clock
> a long time back (can't fix that as it's ABI...)
> 
> We could smooth it in the driver, but if you have
> the option, I'd just change the default clock from userspace.
> Take a look at current_timestamp_clock in sysfs.
> You should be fine with "monotonic"
> 

We will switch to the monotonic clock for now :)

Thanks

/Sean

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2023-01-10 13:27 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-09  7:54 fxls8962af: RTC and NTP Sean Nyekjaer
2023-01-09 15:39 ` Jonathan Cameron
2023-01-10 13:26   ` Sean Nyekjaer

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.