On Wed, Dec 22, 1999 at 03:38:25AM +0100, root wrote:
>
> On Mon, 20 Dec 1999, Alex Dubov wrote:
>
> > [EMAIL PROTECTED] wrote:
> > > This is not likely for technical reasons.
>
> Victor, could you elaborate on it? What reasons?
>
The major performance advantage of RTLinux over Solaris is that we decouple
RT from Linux. There is no way to make linux work fast on average case
and also do a decent job on worst case.
> > I solely agree with this too. But my work lies primary in the
> > servocontrol areas (with a 10msec tasks). In these areas it is
>
> > > We are moving towards a "debug under pthreads/ run in kspace" functionality.
> > >
> > So the whole linux community (with the SGI's kernel debugger). But I
> > still insist, that all processing must be done in the user space (in
> > accordance with TS systems policy).
>
> So you do not need RTL, you need KURT, or RED-Linux. Both of them need
RED-Linux is RTLinux with a different scheduler, as far as I can tell.
Note that Vanilla 2.3 Linux does millisecond timing pretty well.
> > Because of some inherent problems in the kernel module mechanism, many
> > SC drivers are unable to properly save the context of the respective
> > cards, when computer goes to sleep; this renders the use of these cards
> > impossible after wake-up, untill a hard reset is performed (of course,
>
> What about write only registers? Making driver to be able to restore any
> given config in the middle of any operation is very complex. Much easier
> would be just to reload a module, or implelent software reset (config
> settings lost from the card, but application may set them again).
Some cards are not so well behaved, but I think there are limits to what
one can do in software to compensate. What makes RT interesting is that
it requires some careful analysis of tradeoffs .
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/