Linux-kernel mailing list archive 2000-26,: Re: a joint letter on low latency and Linux

# Re: a joint letter on low latency and Linux

yodaiken@fsmlabs.com
Thu, 29 Jun 2000 21:22:39 -0600

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Paul Barton-Davis: "Re: a joint letter on low latency and Linux"
- Previous message: Paul Barton-Davis: "Re: a joint letter on low latency and Linux"

On Thu, Jun 29, 2000 at 06:38:53PM -0700, Linus Torvalds wrote:
> The number of problems that really need RT-linux is practically zero for
> normal uses. This is, btw, why I've never applied the RTLinux patches to
> the standard kernel tree. My personal opinion is that the RTLinux patches
> should _not_ be available by default, so that only people who really need
> the functionality start using it.

The interesting question is what happens when you have 3 Gbit ethernet
feeds with 20 video and audio streams over them and you want to ensure
a baseline level of service for all of them. How do you do this without
some fundamental hard RT.

But, it's certainly true that having hard RT available presents
kernel/driver programmers with an almost irresistable method of compensating
for poor code and that it would only take a small number of hacks
to make the system unusable.

>
> Having non-hard-RT users start using the RTLinux functionality would be a
> disaster, in my opinion. The programming-interfaces are much more
> cumbersome, and the ways of making the system lock up hard are many and
> varied.

I don't know about cumbersome, but to have hard RT, you must give
programmers full authority over the processor time and this is really a
dangerous tool. On the other hand, non-RT driver writers can easily hose the
machine too.

> If you do a computer-controlled radiation-dose machine for treating
> patients, and the latency guarantees have to be in the sub-100ms range,
> THEN you should use RTLinux.

Please read what the GPL says about liability -)

> If you're doing just audio that needs approximately 1% fo the CPU
> resources, and you have to use hard-realtime, the system needs work. Using
> RTLinux is a way of saying "oh, we can't fix this properly@.

If there was a brilliant method of rearranging memory that required once
a minute, for 20ms no Linux user task advance, so that kernel compiles and
Oracle and Apache ran 500 times faster, wouldn't it be worth it?
Optimizing for average case and response time is what Linux should do,
optimizing for worst case is what the RT side should do.

Linux should have better latency, but programs that depend on hard timing
properties of the kernel are unfortunate.

    --
    ---------------------------------------------------------
    Victor Yodaiken
    FSMLabs:  www.fsmlabs.com  www.rtlinux.com
    FSMLabs is a servicemark and a service of
    VJY Associates L.L.C, New Mexico.

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

- Next message: Paul Barton-Davis: "Re: a joint letter on low latency and Linux"
- Previous message: Paul Barton-Davis: "Re: a joint letter on low latency and Linux"