Re: [Xenomai-help] Non-deterministic behaviour in primary mode

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2317 bytes --]

Saul wrote:
> Gilles Chanteperdrix wrote:
>>  > >  > > I thought SMI was supposed to increase latencies, but I only
>>  > >  > > see latencies < 60us at any load, unless I start video
>>  > >  > > capture. Does the latency test absolutely rule out SMI as
>>  > >  > > the cause?
>>  > >  >
>>  > >  > Not really, e.g. if the video capture device is USB-attached,
>>  > >  > then SMI could possibly remain in the picture.
>>  > >
>>  > > I have used the bttv driver with xawtv or mythtv and nvidia
>>  > > proprietary drivers on a dual pIII machine running latency and
>>  > > the maximum latency was far less than 100 us. What produces large
>>  > > spots, however, is switching virtual terminals or changing
>>  > > resolution. Doesn't xawtv change resolution for full screen mode
>>  > > ? Did not you use the 768x576 modeline hack ?
>>  >
>>  >
>>  > The video capture is not USB, it's a PCI card. Since I don't see
>>  > poor latencies I'm guessing my problem is *not* SMI related.
>>
>> The latencies above 100us that you observe when starting video capture
>> are abnormal. I was suggesting that these latencies are not due to
>> video capture but to the fact that xawtv change resolution. Big
>> latencies when switching virtual terminal are a well-known issue, not
>> related to SMI. So my question was: is xawtv configured on your
>> machine to change resolution when starting capture ?
> 
> Oh, well xawtv starts up in a window and does not change the screen
> resolution. The large latencies occur during program startup. I
> have seen no other program produce poor latencies in the latency
> test program.
> 

There is a way to narrow down your issue: apply the ipipe latency tracer
patch on top of your current Xenomai kernel, switch tracing on in the
config (ipipe feature), and recompile the kernel. Then you should run
the latency test with the -f parameter.

After hitting a high latency, grab the content of
/proc/ipipe/trace/frozen. This back-trace is taken always for the
highest latency the test tool measured.

You may want to play with /proc/ipipe/trace/back_trace_points (even
belatedly), or .../verbose to see more details. Look for high delays
before or after the timer interrupt - or post a (packed) version of the
trace to the list.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]