Re: [Xenomai-help] RTCAN and tsc

[Roland Tollenaar <rwatollenaar@domain.hid>]

Hi,



Gilles Chanteperdrix wrote:
>>> Enable the I-pipe tracer, recompile your kernel, set
>>> /proc/ipipe/trace/back_trace_points to a larger value, and run latency
>>> with the -f flag. Show us the contents of /proc/ipipe/trace/frozen, and
>>> we may be able to give you an answer.
>>>
>>> For more details on the I-pipe tracer, see:
>>> http://www.xenomai.org/index.php/I-pipe:Tracer
>> Attached find the traces. The first one , frozentrace.txt is without
>> my application running.
>>
>> The frozentraceApptxt with my app running and frozentrace_rtcanrecv
>> with the node  alive but only read by rtcanrecv.
> 
> frozentraceApp.txt:
> 
> :|func     -217!  rtcan_sja_interrupt (xnintr_irq_handler)
> :|func      -96   rtcan_rcv (rtcan_sja_interrupt)
> 
> 
> and frozentrace_rtcanrecv.txt:
> 
> :|func     -164!  rtcan_sja_interrupt (xnintr_irq_handler)
> :|func      -39   rtcan_rcv (rtcan_sja_interrupt)
> 
> look very consistent: the call to rtcan_sja_interrupt eats more than
> 100 us.

What does this mean? This is as good as it gets? That is a problem. I 
have a couple of thousand euros of new hardware betting on xenomai/rtcan 
being real-time enough to do some serious feedback control of machinery. 
Must I put that up for sale now? I'll start writing my resignation 
letter......:(

But more seriously rtcan_sja_interrupt I presume is a routine (interrupt 
handler?) by the sound of things related to the sja chip. Is the 
conclusion that something is wrong in rtcan_sja? Surely timing 
inconsistencies of 200 micro seconds cannot be design?


I will not be able to work on this tomorrow. So if I make less noise on 
the list its only because I am on a plane not because I have lost 
interest. :)

Regards,

Roland

>