Re: [Xenomai-help] [Ethercatmaster-users] EML conflict with RTCAN? low_level_input framebuilding failed.

[Roland Tollenaar <rwatollenaar@domain.hid>]

Hi,

Some more interesting findings (no i-pipe trace yet though).

> Hmm, this doesn't convince me yet. Such skews during startup may as well
> be triggered by unusual load during runtime (non-RT activity or new RT
> components). Did you put your system under adequate non-RT load as well
> while measuring the outputs?
Running latencytest with my application shows an average latency of 
about 40 and a max of 200ns. This was rather shocking so I turned off 
rtcan in my application. Now the max latecy is 60ns. Turn off EML and 
turn on rtcan, max latecy is 230ns. How is that for strange? But since I 
can see the scope output bobbing with 200ns during the latency test, I 
can also see that if I run my application without the latency test the 
huge max latency disappears entirely. Maybe it is time for the trace but 
then again I am still using CAN over the parallel port so will see what 
it does on a machine with a PCI CAN adaptor first. Because I think I 
know what happens: Due to the external loading the CAN recv interrupt 
triggers the Rx ISR briefly before the 1ms task period ends. Due to the 
priority of the ISR (huge debate over this) and its atomicness (if I 
remember correctly) the reading out of the slow hardware delays the 
start of the new task period.

Just thought it was interesting to mention. Btw when the latency appears 
there are no overflow messages or anything like that which support the 
theory I have about the cause.

Btw2 the 200ns latency spikes do not cause the scope to loose lock on 
the saw-tooth so whatever causes that problem is of a different nature 
still.

Regards,

Roland.



> 
>> I will keep the check disabled but for the EML chaps I do think this is
>> a point of interest. I would be very interested how this index shift
>> occurs and why it is persistent after occurring once.
>>
>> Sorry for the pragmatic qualifications here but in the end its the
>> stability of the outputs that will determine the behaviour of the
>> machine so its not a bad way to assess the software. :)
> 
> A problem isn't solved until it is also understood.
> 
>>> If the problem persists (or your _really_ want to understand what
>>> happens), you could try to put an xntrace_user_freeze(0, 1) before the
>>> line which emits that EML warning, turn on the I-pipe tracer, set a
>>> large back_trace_points value (a few thousand), enable verbose mode, and
>>> grab what /proc/ipipe/trace/frozen reports after the hick-up. See [1]
>>> for more howtos.
>> Done this before so it should not be a problem. Don't think it is
> 
> In that case, I would even more suggest to collect the data, maybe now
> about the fragile startup case.
> 
>> necessary quite yet as the behaviour at the moment looks good.
> 
> Jan
>