Re: [Xenomai-core] Synchronising TSC and periodic timer

[Jan Kiszka <jan.kiszka@domain.hid>]

Gilles Chanteperdrix 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...
> 
> 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. */
> 

Ah, I see. Hmm, wouldn't this create some "resolution hole" between the
time offset_ns exceeds a precise period and the time the next IRQ
actually strikes? The returned timestamps would then just stick to last
(irq_tsc + irq_jitter_ns) until the next update occurs.

Jan