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...

Here is what I meant:

[timer IRQ]
irq_tsc = rdtsc();
irq_jitter_ns = read_8254()

[xnpod_gettime_offset]
offset_ns = tsc2ns(rdtsc() - irq_tsc()) + irq_jitter_ns
if (offset_ns > period_ns)
    offset_ns = period_ns; /* Avoid non monotonic clock. */

-- 


                                            Gilles Chanteperdrix.

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

Reply via email to