I think I can give an example of an application needing bounded RT
latency. This is not Richard's application.
We have a planned particle physics application, where a large pool of
processors (a few hundreds or thousands) analyse events from a particle
detector in order to find the interesting events.
First, the detectors feed data at a very high rate to some memory
buffers. Prelimary electronics discards the most trivial non-events.
For each event after the electronic filter, a processor is chosen and
sent a packet telling it to analyse the event, and which memory buffers
to fetch data from. The processor must respond in a bounded time to
that packet, by requesting and retrieving the data from the relevant
memory buffers before the buffers overrun.
It isn't possible to simply send the data to the processor, because most
of the time, not all the data is needed to make a decision. And sending
all the data would be more than the network infrastructure could handle.
Experiments and theory have shown that one of the most important
parameters in determining how much data can be handled, is round-trip
latency. Simply buffering more data is not a solution, because
buffering has its own overheads. (On a PC, the most obvious is cache
pressure). Also we're talking about a very high data rate (thousands of
gigabit rate links in parallel), and a small increase in latency
corresponds to a rather large increase in buffering requirements.
Why isn't it all done with a special operating system? (Apart from the
expense and maintainability issues). Because when the data is received
by a processor, it goes through various filtering and processing stages
that get successfully more complex (but at lower data rates), and that
dataflow is best handled within a single machine, using ordinary
programming techniques. These include having a decent operating system
handy -- Linux seems like a good choice.
Multiple threads (one per active event on this processor) are used
because of the different filtering layers: the later filtering stages
are quite slow (involving lots of maths), but the initial stages must
respond to the network in a timely fashion.
By timely, I mean that the RT latency of the thread which responds to
new event packets and control packets must be bounded, or at least be
within a bound with some measured probability quite close to 1.
It would be very helpful if the measured latency did not vary according
to the non RT load, which of course depends on the precise formulation
of the event filtering code, which is apt to keep changing for different
experiments.
Latency is even in issue communicating within the analysis programs,
because of cache locality effects. But that's a separate programming
problem, not relevant to linux-kernel.
Hope this inspires!
-- Jamie
-
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/