Fusion and RT Rreempt [Was: RTAI/fusion 0.7.2]
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
>>> Interrupts are coming in with 4msec interval.
>>> Worst measured latency was 66052 cycles, which is 36794 nsec (36.8
>>> Running 'latency' test from testsuite gives:
>>> RTS| 2951| 3550| 13571| 0|
>>> 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
> 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
More information about the Rtai