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