Rodrigo Rosenfeld Rosas wrote:
Philippe Gerum wrote:

Given the description above, just that some skin might return either
nucleus ticks or corrected timestamps to the applications, which would
in turn do some arithmetics for converting values they got from the skin
between both scales internally, and mistakenly use the result while
assuming that both scales are always in sync. In this situation, and
during a fraction of the time (i.e. the jitter), both scales might not
be in sync, and the result would be unusable.

But I still can't find a real situation where the user would need these values to be in sync...

But maybe we are still discussing different issues actually, so it would
be useful that the core issue that triggered the discussion about
periodic mode precision be exposed again.

The core issue is that:
I think the driver development should be kind of independent from the user programs. That said, if the driver needs a precise timestamp, it should be able to get it, even if the user is fine with a, say, 100ms periodic tick. If the user have a loop with a deadline of 100ms, and if it takes two consecutive images for estimating speed in the same loop, the user will need to have a higher precision timestamps for the images. So, the driver will need a high precision timer reading for making possible to provide those timestamps...

This is exactely what rt_timer_tsc() or clock_gettime(CLOCK_MONOTONIC) [or whatever ends up calling xnarch_get_cpu_tsc() from the underlying architecture] are there for.

The thing is that rt_timer_read() is expected to return values compatible with the timer mode, always. But rt_timer_tsc() is there to return the most precise timestamp available from the underlying architecture, regardless of the current timing mode. If no TSC exists on x86, then it is going to be emulated (using the PIT's channel #2), but in any case, you will get a high precision timestamp, up to the best precision the architecture can provide, that is.

The key issue is to acknowledge the fact that periodic ticks and precise timestamps are two _unrelated_ units. What I'm reluctant to is to try finding some artificial binding between both units, because there is none (being stable, that is).

In your example above, you would be able to estimate the elapsed time using something like rt_timer_tsc(), and convert this to ticks using rt_timer_ns2ticks(rt_timer_tsc2ns(timestamp)). The main problem would be the rounding here, and work around the lack of precision the periodic mode currently exhibits due to the constant delay between timer shots.

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)

I hope that was what you were asking for...



Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!

Xenomai-core mailing list



Xenomai-core mailing list

Reply via email to