Fusion and RT Rreempt [Was: RTAI/fusion 0.7.2]

Philippe Gerum rpm at xenomai.org
Thu Jun 2 08:52:06 CEST 2005

Max Krasnyansky wrote:
> Philippe Gerum wrote:
>>> Same application: Interrupt on parallel port handled by kernel task. 
>>> Task saves TSC and
>>> wakes up user-space task via the sema4. User-space task reads TSC and 
>>> computes the latency.
>>> This time I disabled outb() completely because I don't use oscope any 
>>> more.
>>> Interrupts are coming in with 4msec interval.
>>> Worst measured latency was 66052 cycles, which is 36794 nsec (36.8 
>>> usec).
>>> Running 'latency' test from testsuite gives:
>>>     RTS|        2951|        3550|       13571|       0|    
>>> 00:03:02/00:03:02
>>> Even under heavy disk and network load.
>> ...yummie... Good to hear this. Now that the infrastructure is stable, 
>> we have just entered a careful optimization phase of the nucleus along 
>> with the scalability improvements Dmitry's in working on. Hopefully, 
>> this will have a positive impact when running on low-end hw too. 
> Yeah, but result from my app does not look very good, does it ?
> I mean 36.8 usec from kernel task to user task.

Sorry, I misinterpreted your figures, thinking 36.5 was observed during 
your previous tests.

  There is also about 5 usec
> worst case interrupt dispatch latency (measured long time ago with oscope).
> So the total is more than 40 usec to propagate interrupt into the 
> user-space.
> Remember when you and Paolo said that you're seeing 15 usec worst case
> latency. I said that it's with the timer compensation and stuff, actual
> interrupt response time is much worse.

The problem here is likely your period: 4ms allows regular Linux 
activities to trash the context much longer than when running a 10 Khz 
period, which is the usual way we run our tests. Any difference with -p 
100 ?

> Max



More information about the Rtai mailing list