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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list [email protected] https://mail.gna.org/listinfo/xenomai-core
