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 email@example.com
Please read the FAQ at http://www.tux.org/lkml/