Re: a joint letter on low latency and Linux

[Larry McVoy]

> On Thu, 29 Jun 2000, Larry McVoy wrote:
> > OK, now we are getting somewhere.  So I have a kernel level source, user
> > level processing, and a kernel level sink, right?  And the problem is that
> > we can have long delays which mess that up.  Here is how you handle that
> > with RTLinux:
> 
> Well, I personally would rather see that nobody ever needed RTlinux at
> all. I think hard realtime is a waste of time, myself, and only to be used
> for the case where the CPU speed is not overwhelmingly fast enough (and
> these days, for most problems the CPU _is_ so overwhelmingly "fast enough"
> that hard realtime should be a non-issue).
> 
> I definitely agree with low-latency requirements even in a standard Linux.
> I just disagree violently with doing them with horrible cludges instead of
> working on doing it right.

I guess the problem I have is that I don't see a clean way to make sure
that no high latency events ever creep into the kernel.  I'm 100% in
agreement with the idea that all code paths through the kernel should
be short and sweet, but that isn't always the case.  All it takes is
one misbehaving driver that hangs onto the CPU too long and you missed
your deadline.

I'm not a fan of realtime either but I hate half assed realtime creeping
into a time sharing kernel - everything I know personally or have read
about says that this is a bad idea.

Given all that, if you want to take a Linux box and use it to drive a
pile of devices with hard guarentees (think factory floor, CNC devices,
mixers, lots of stuff that is currently done in ASICs), then you need a
better answer than Linux gives, even with the Ingo patches.  

Do we just ignore that space?  

Seems like we are close to having a decent answer, why not support it
for those applications?

I'd rather support RTLinux than see lots of kludges being slipped into
the generic kernel.