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?


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to