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

[Philippe Gerum <rpm@xenomai.org>]

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...
> 
> Regards,
> 
> Rodrigo.
> 
> 		
> _______________________________________________________
> Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
> http://br.acesso.yahoo.com
> 
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
> 


-- 

Philippe.