Mon, 13 Nov 2000 Denis Karpov wrote:
> hello,
>
> On Fri, Nov 03, 2000 at 08:35:03PM +0100, David Olofson wrote:
>
> # If you're going to use threads (as opposed to the ISR/callback model), you
> # could try user space pthreads. This is more familiar to RTL threads, and you
> # don't have to know *anything* about kernel hacking to get started.
>
> # As for performance, the only options that deliver reliable scheduling in the �s
> # range are signals to user space from some RTX (currently RTAI and RTL does
> # this), and of course the Real Thing; RTL, RTAI or similar (any others using
> # this kind of model?) RTK solution.
>
> # Next best is user space pthreads on Linux 2.2.10-lowlatency (*). This is just
> # a matter of using a lowlatency kernel - you run the same code, using
> # SCHED_FIFO or SCHED_RR, just as you would without the lowlatency patch.
>
> the problem is, i have to decide wether to use rt(rtai) linux or not (probably use
> of `straight` linux would be fairly sufficient). I have to deal with proprietary
> hardware. Generally it can be described as follows:
If you're worried about what closed source drivers might do to the RT
performance (as a result of not being compiled with an RT kernel), you're in
serious trouble if it should turn out that you need hard RT. In that case, I'd
use different hardware, if at all possible, unless something could be worked
out with the vendors.
Besides, if those drivers have to be used from within RTL/RTAI threads, and you
don't have the driver sources available for porting, you're out of luck. RTL or
RTAI won't be of much help to you, as your I/O will be crippled by standard
Linux and the drivers...
However, Linux/lowlatency *might* still work (very probable, actually) even if
you can't get the driver sources to recompile or port. As long as the drivers
don't do Very Bad Things (such as busywaiting or holding important spinlocks
for "ages"), they won't interfere with Linux/lowlatency performance, and your
application will get sub ms peak scheduling jitter.
> - linux boots from flash, creates ramdisk and further operation occures in ram only
>(i.e. no hard disc and associated io overhead)
> - the hardware interrupts are mostly coming from two communication interfaces
> - the processor is equivalent of PIIx400
>
> the os and software should be able to handle the maximum load which hardware is
> able to process.
Which is what, and bound to what...?
(I mean, if you're CPU bound, you're in *real* trouble! There's no such thing
as the absolute fastest optimization of any given code of significant size...
No OS in the world will help you there, as you'll have to run without one just
for *starters!* ;-)
> i have to find out the realtime requirements. but since i'm no hardware guy,
> i don't know the hardware chipset characteristics (i assume this should be the
> starting point).
Well, yeah, but at the same time, as long as you're not going to hack your own
OS, it's also the smallest problem. Finding a good RTOS for any given hardware
is more troublesome than getting hardware that could, in theory, provide good
RT performance. (I've never seen a machine so far with serious, unfixable RT
problems. The most common problem is probably sloppy "super-NMI" power
management, and that can be disabled in the BIOS config.)
> could you advise approach how to estimate realtime requirements of such task ?
Hmm... This is (in theory) very simple:
1) How long is your system allowed to take to output a correct response to any
given input data, on average?
2) How long is your system allowed to take to output a correct response to any
given input data, in the worst case?
* If 1) is in the ms range, you can go with standard Linux.
* If 1) is in the fractions of ms range, you can still go with standard Linux,
but do note that the frequency of missed deadlines may become a significant
figure.
* If 2) is more than some 200 ms, you *may* get away with standard Linux, but
DON'T expect that you'll never see longer latencies than that! Several
seconds have been observed, although on systems with lots of memory and disk
I/O. You *may* not see that big peaks on your particular configuration.
* If 2) is definitely hard, as in "property or life will be at risk if
deadlines are missed", you *have* to go with a real time OS, like QNX, RTL
or RTAI.
* In all practical applications, except the critical class mentioned above,
Linux/lowlatency seems to be usable for hard RT, provided that 2) is higer
than 1 ms. (Probably lower on your CPU, but as you're close to the jitter
margins here, you should better test this carefylly on your system, and add
sufficient margin to provide the reliability you need.)
> are there any reviews of performance of standard linux vs. realtime on different hw
> platforms ?
I don't know of any benchmarks or such for other than x86 based systems, but
AFAIK, x86/PC is one of the sloppier architectures when it comes to interrupt
handling. Most other architectures should do better; especially ones that
depend less on cache and more on raw memory speed, and CPUs with shorter
piplines.
//David
..- M u C o S -------------------------. .- David Olofson --------.
| A Free/Open Source | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
| for | | Open Source Advocate |
| Professional and Consumer | | Singer |
| Multimedia | | Songwriter |
`-----> http://www.linuxdj.com/mucos -' `---> [EMAIL PROTECTED] -'
-- [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/
