Re: a joint letter on low latency and Linux

[Steve VanDevender]

Paul Barton-Davis writes:
 > >There are two different problem spaces:
 > >1. Live -- which seems to me to be a hard realtime application when you
 > >    talk about serious quality.
 > >   Time_data_in - Time_data_out < K 
 > 
 > I ask you again, just as I asked Larry: if K was 10 seconds, would
 > anyone characterize this as "hard realtime" ? 

If, for the purpose of your application, some event _must_ be processed
within a definite amount of time, then yes, it is hard realtime, whether
that amount of time is a microsecond or an hour.

Timesharing systems do not give you such guarantees; their scheduling is
intended to provide equitable access to the CPU for an arbitrary number
of processes, not guaranteed response for any of them.  Device drivers
servicing interrupts have mechanisms to obtain guaranteed response to
their events, but these mechanisms are not available to user processes.

What I see some proponents saying is "we don't need hard realtime, we
just need guaranteed response within 10 ms".  That's an inherent
contradiction.  Hard realtime is not a matter of the desired response
period, but whether your application suffers fatally if it cannot do
something within a guaranteed maximum amount of time.

This all came up before in a previous flamewar.  Reducing Linux's
scheduling latency and overhead is good.  Trying to make Linux serve the
contradictory goals of being both a good timesharing OS and a good
realtime OS is not.  Thinking that you are making Linux into a realtime
OS by reducing scheduling latency and overhead is a fallacy.