Re: a joint letter on low latency and Linux

From: Zdenek Kabelac (kabi@fi.muni.cz)
Date: Mon Jul 03 2000 - 08:02:02 EST


Linus Torvalds wrote:
>
> 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

I would really like to know how to control robots without RTL - if you
think I could leave robot-arms for 5ms without commands, you are
definitily
wrong.

I'm watching this long debate - and the more I read the more I get
confused -
with this approach to the problem I'm getting feeling, that the Linux
is simple bad choice for big range of applications and it will stays
this way
forever.

Why there just can't be an option for RT processing ? - if someone
doesn't needed it,
it may leave it turned off (with all the drivers who need RTL
inaccessible).
Its not a problem for me to reapair rejects when applying RTL patches
to
newer kernel, however I don't think it should stay this way forever.

This is realy something I don't understand.

> these days, for most problems the CPU _is_ so overwhelmingly "fast enough"
> that hard realtime should be a non-issue).

Again wrong (thought I'm not using 900MHz Duron) - the computers will
never be fast enough! (I think B.Gates gets famous for sentences like
this)
You can always ask to do more jobs for the computer.

And speeking about non-rtl responsivity - even with `nice 20` I had to
kill
seti client on my dual CPU 480MHz when I normaly work with it - as I
could feel the 'slowness'
caused by this low priority task (using 2.2.17pre9-SMP kernel)
(BTW once I had a patch (2.2.14 kernel) called ADAPT which dramaticaly
increased responisivness of the whole system (I could run even e.g. two
burnBX
program without even knowing about them - this patch has never been
discussed on
linux konference)

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

Could you look at the RTL patch please and point out which parts do
you consider as a horrible cludge - as this is the only way it could
be fixed/improved.

I can always hear that Linus(you) won't allow the RTL to go into
mainstream kernel
because its uggly hack, however I would like to know the reason for
this,
and also I would like to know what should be fixed and why this can't be
included
as an experimental feature?

bye

-- 
             There are three types of people in the world:
               those who can count, and those who can't.
  Zdenek Kabelac  http://i.am/kabi/ kabi@i.am {debian.org; fi.muni.cz}

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



This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:12 EST