Re: a joint letter on low latency and Linux

Benno Senoner (sbenno@gardena.net)
Fri, 30 Jun 2000 15:54:33 +0200


> -- > I want to try this trick on TCP/IP sometime.
>
> I think having RTLinux going in and grope the kernel all over is just
> asking for trouble. That path leads to madness. It will add a tight
> dependency between the internals of Linux and RTLinux. Take it from
> someone who knows: tracking kernel drift is a bitch.
>
> Again: this is why I like my idea of scheduling user-space RT
> processes with the RTLinux run queue. Only a few well-defined places
> are needed for Linux/RTLinux to co-operate.
>
> Regards,
>
> Richard....

But your approach still doesn't solve the problem,
since at some point you have to call write()
( to write the stuff to the soundcard)
within the RT userspace thread.
At this point you give up RT privileges (because syscalls
are not allowed), than then you face the usual 100msec worst
case latencies.

As said I see only two solutions:
stay in RTLinux / RTAI all the time (by using custom ported
soundcard drivers)

or stay all the time in userspace ( SCHED_FIFO + mlockall() )
and provide a kernel which ensures worst case scheduling latencies
in the range of a few msecs)

A hybrid solution does not bring us any advantages in our cases.

Benno.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/