Fillod Stephane wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>  > Likely too simple: The periodic IRQ seems to pop up on every CPU
> so that
>>>  > the TSC could be recorded, but will this happen synchronously? At
> least
>>>  > we will see (IRQ) jitters, and those jitters could already create
> in the
>>>  > single-CPU case a non-monotonic clock...
>>>
>>> I do not know how this issue is solved in Linux, but there seem to be
> a
>>> simple solution: before adding the tsc offset to the last tick time,
>>> this tsc offset should be compared with the tick duration in tsc
>>> counts; if it is greater, then replace with the tick duration in tsc.
>>>
>> Hmm, I would rather express it in absolute tsc values, i.e. always save
>> the tuple (absolute_tsc, jiffies):
>>
>> [timer IRQ]
>> new_tsc = read_rsc() - old_tsc;
>> if (new_tsc < old_tsc + period_in_tsc_ticks)
>>      new_tsc = old_tsc + period_in_tsc;
>> old_tsc = new_tsc;
>>
>> Disclaimer: I haven't thought about potential accuracy side effects of
>> this implementation, e.g. what would happen over the long term if the
>> condition is always fulfilled and executed...
> 
> Aha! the wonderful world of PLL's :-)
> 

Yes! I was waiting for someone to throw this in ;). But do we really
need them, or are there so cheap implementations that the overhead
doesn't matter?

Jan

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to