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

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

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

Rodrigo Rosenfeld Rosas wrote:
> Em Segunda 20 Março 2006 13:51, Philippe Gerum escreveu:
> 
>> ...
>> I think that you should try convincing Jan that rtdm_clock_tsc() might
>> be a good idea to provide, instead of tweaking rtdm_clock_read() in a
>> way which changes its underlying logic. ;o)
> 
> Yes, that is exactly what I want! :)
> I don't see any reason for changing rtdm_timer_read() neither. I think that 
> the most common usage of high-precision timestamps is for relative time 
> cases. It doesn't need to be in sync with Xenomai's timer... It is best to 
> keep things simple.
> 
> What do you think Jan?

We discussed a lot about how to prevent the user shooting him/herself in
the knee with inter-tick timestamps, but I still think that
rtdm_clock_read_tsc() would even be worse in this regard.

xnarch_get_cpu_tsc() and derived skin services are not supposed to
deliver consistent results across multiple CPUs, are they? While the
user could avoid such scenarios by locking tasks on a specific CPU,
drivers cannot - at least so far. So, to safely introduce such a
low-level service for RTDM, I think we need

A) CPU affinity for RTDM-registered IRQs
B) CPU affinity for RTDM kernel tasks
C) Some well written docs, explaining how to safely use TSCs at driver
level and how to provide them to the user (the latter aspect makes me
worry most)

While A) and B) might be useful for other (though rare) scenarios as
well, C) will still require a very good understanding and interface
design from the driver writer, while I don't see comparable error
dimensions with the improved rtdm_clock_read(). Comparing apples
(rtdm_clock_read()) to oranges (rt_timer_read()), there will be some
error around a tick period. But comparing apple[0]
(rtdm_clock_read_tsc() on CPU#0) to apple[1] (rtdm_clock_read_tsc() on
CPU#1), the error could become *much* larger and the design and
documentation effort to avoid this will be significant.

Ok, as a simple resolution for this problem, I could imagine introducing
a TSC timestamping service to RTDM that always fall back to that level
of accuracy which is guaranteed to be consistent - either because we run
in aperiodic mode, or on uniprocessor, or thanks to some magic
synchronisation between all CPU clocks. This would have to be decided at
build time, in the first version likely by checking for (multiprocessor
|| aperiodic) to switch to xnpod_get_time().

Jan


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