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

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

[-- Attachment #1: Type: text/plain, Size: 2647 bytes --]

Philippe Gerum wrote:
> Jan Kiszka wrote:
>> ...
>> On the other hand, the advantage of TSC-based synchronised inter-tick
>> timestamps is that you can do things like
>>
>>     sleep_until(rt_timer_ns2ticks(rtdm_clock_read() + 1000000))
>>
>> without risking an error beyond +/- 1 tick (+jitter). With current
>> jiffies vs. TSC in periodic mode, this is not easily possible. You have
>> to sync in the application, creating another error source when the delay
>> between acquiring the TSC and sync'ing the TSC on jiffies is too long.
>>
> 
> The proper way to solve this is rather to emulate the periodic mode over
> the oneshot machinery, so that we stop having this +/- 1 tick error
> margin. The periodic mode as it is now is purely a x86 legacy; even on
> some ppc boards where the auto-reload feature is available from the
> decrementer, Xeno doesn't use it.
> 
> The more I think of the x86 situation, the more I find it quite silly. I
> mean, picking the periodic mode means that 1) all delays can be
> expressed as multiples of a given constant interval, 2) the constant
> interval must be large enough so that you don't put your board on its
> knees, by processing useless ticks most of the time. What one saves here
> - using periodic mode - is a couple of outb's per tick on the ISA bus,
> since the PIT handles this automatically without software intervention
> once set up properly. We already know that the programming overhead
> (i.e. introduced by those outb's) is perfectly bearable even for high
> frequency sampling like 10Khz loops in aperiodic mode. So why on earth
> do we care about saving two outb's and get a lousy timing accuracy in
> the same move, for constant interval delays which are necessarily going
> to be much larger than those already supported by the aperiodic mode? Er...
> 
> This is a shift in the underlying logic of the periodic mode we are
> discussing here actually. It used to be a mode where timing accuracy was
> only approximate, mostly to deal with timeouts, in the watchdog sense.
> Now, it is becoming a way to rely on a constant interval unit, while
> still keeping a high timing accuracy. I'm ok with this, since we don't
> rely on true PIT (except for x86, which is fixable) when running in
> periodic mode, so I see no problem in raising the level of timing
> accuracy of such mode. Existing stuff would not break because of such
> change, but improve instead for people who care for exact durations in
> periodic mode.

Yep, getting rid of as much periodic mode limitations as reasonable in a
transparent way sounds very good to me.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]