Re: real-time threaded IO with low latency (audio)

yodaiken@chelm.cs.nmt.edu
Fri, 23 Jul 1999 10:16:56 -0600


On Fri, Jul 23, 1999 at 11:08:31AM -0400, Sam Roberts wrote:
> Its pretty close to correct. If the RT tasks need the O/S services to
> perform they're rt function, as oppossed to your logging scenario where

If you need service X to be realtime, then you can't rely on a nonrealtime
service. For sure. But Linux services are available to the RTL rt tasks, its
just that the RTL tasks can't magically make Linux services be realtime.

> the logging passive and doesn't feed data back into the rt system, then
> they inherit the determinism of the *least* deterministic part of the
> system. If you're running an 200Hz controller that expects setpoints
> via a udp connection at 40 Hz, and is loggin large amounts of data, you're
> "real time" controller is going to be affected by the non real-time
> nature of the user-space activities. This is not good. Note that the

Not unless it relies on the UDP packages coming in at a fixed rate. But
relying on precise timing of UDP packages seems a little peculiar anyways.

> disk logging and the gui displaying progress charts, and the tcp are all
> logically disconnected systems, the only necessary shared resources are
> CPU time, and irqs, so they shouldn't have to affect each other, but they
> are too closely coupled under Linux right now.

Au contraire. Those systems are closely coupled on Linux because the micro-kernel
experiment showed the consequences of separating them.

Process 1 Process 2 Process 3
read data from a RT pipe and read from the file Gnuplot
write to disk on the FS do computation
output to standard out

The closely coupled OS will correctly note the shared data between
the three processes for a major performance win.

-
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/