Re: [rtl] RTLinux + UMLinux ???
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 t
Re: [rtl] RTLinux + UMLinux ???
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:
- 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.
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).
could you advise approach how to estimate realtime requirements of such task ?
are there any reviews of performance of standard linux vs. realtime on different hw
platforms ?
thank you for information,
Denis.
--
("\''/").__..-''"`-. . [EMAIL PROTECTED]
`9_ 9 ) `-. ().`-._.`) http://www.lut.fi/~karpov/
(_Y_.)' ._ ) `._`. " -.-' +358 (0)40 502 0931
_..`-'_..-_/ /-'_.' Lappeenranta University of Technology
(l)-'' ((i).' ((!.'
*** Give a man a fish and he will eat for a day. Teach him how to fish,and he will
sit in a boat and drink beer all day. ***
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
Re: [rtl] RTLinux + UMLinux ???
[EMAIL PROTECTED] wrote: > > On Sat, Nov 04, 2000 at 03:29:19AM +0100, Bernhard Kuhn wrote: > > Denis Karpov schrieb: > > > > > is it possible to run RTLinux in User Mode Linux > > > > I didn´t tried it, but it´s rather unlikly that it > > will run: the UML-Kernel is patched in the areas > > of memory management, process scheduling and interrupt-handling > > in order to be able to run as usual application. > > > > I doubt that the rtl-patch could be applied without > > rejects to a kernel prepatched with UML. > > Even then, you have to redo the same work as for > > the kernel-scheduler etc. Beyond all this problems, > > the UML-RT-kernel wouldn´t be real-time capable any more. > > > > BTW: Everybody laughs about "printf-debugging" (means > > writting message-bytes to the printer port), but IMHO, > > for many hard-rt-applications(!) this is a quite > > convenient way to get programms bug-free. > > > > Other possibilites: R2D2 from Zentropics and LXRT from RTAI. > > Alternative include > 1. gdb which comes with RTLinux, > 2. XBD the CAD-UL remote debugger for RTLinux, > 3. CarbonKernel the RTLinux V3 emulation. > Also, the remote kgdb+kmod (remote serial gdb), this works with RTL & RTAI. It allows kernel+module+rt-module debugging in the same scope. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTLinux + UMLinux ???
Thu, 02 Nov 2000 Nathan Paul Simons wrote: > On Thu, Nov 02, 2000 at 03:56:01PM +0200, Denis Karpov wrote: > > i have a question. since i'm new to RTLinux and kernel programming i > > need some safe way to experiment with stuff. > > is it possible to run RTLinux in User Mode Linux > > [http://user-mode-linux.sourceforge.net/] > > > > that means one needs to apply UMLinux and RTLinux kernel patches > > together > > to 'straight' kernel source. is it going to work ? did any1 try it ? > > Don't know about UMLinux, but you might want to try user-level signals > in RTLinux. The actual code still runs in kernel space, but you don't have to > know nearly as much about kernel programming to use it. 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. Provided you don't have a crappy driver or a hardware problem, this schedules reliably with a peak latency below 1 ms, even on low end Pentium systems. (*) AFAIK, never versions still have problems in some areas. The latest patches for 2.4.0-testX seem to be closing up, though. (BTW, power management settings on the BIOS level may break RT performance on some machines! This hits *any* OS; RTOS or not, so there's no other way than to disable APM in the BIOS, or replace the mainboard. It might be a good idea to disable APM in the kernel as well for lowlatency kernels, as this code may occasionally perform lengthy BIOS calls on some machines.) User space pthreads without the lowlatency patch would be the next lower level of performance. The average latency of the best 90% or so schedules is the same as for the lowlatency kernel, but the rest of the time, there will be significantly higher latency peaks. Worst case is unknown, but several hundreds of ms have been observed on machines with lots of non-RT work going on in the background. (Disk access is particularly problematic.) Expect frequent scheduling latency peaks in the 5-50 ms range, unless you throw out all background daemons, disable swap, stay away from disks etc... The worst solution WRT to timing is probably running *anything* under a virtual machine or emulator. The best possible theoretical solution I can see would be running RTL under UMLinux on a lowlatency host kernel. If this doesn't just freeze your system, or deadlock (very likely, unless UMLinux is designed as a *real time* virtual machine...), this could possibly run RTL threads and ISRs with sub ms latencies. More realistically, you'll end up with performance similar to SCHED_OTHER pthreads on a standard Linux kernel, which means frequent delays in the tens of ms range. Not very useful if you code has any kind of dependency on timing... David Olofson Programmer Reologica Instruments AB [EMAIL PROTECTED] ..- M u C o S . .- David Olofson --. | A Free/Open Multimedia | | Audio Hacker | | Plugin and Integration Standard | |Linux Advocate| `> http://www.linuxdj.com/mucos -' | Open Source Advocate | ..- A u d i a l i t y . |Singer| | Rock Solid Low Latency Signal Processing | | Songwriter | `---> http://www.angelfire.com/or/audiality -' `-> [EMAIL PROTECTED] -' -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTLinux + UMLinux ???
On Sat, Nov 04, 2000 at 03:29:19AM +0100, Bernhard Kuhn wrote: > Denis Karpov schrieb: > > > is it possible to run RTLinux in User Mode Linux > > I didn´t tried it, but it´s rather unlikly that it > will run: the UML-Kernel is patched in the areas > of memory management, process scheduling and interrupt-handling > in order to be able to run as usual application. > > I doubt that the rtl-patch could be applied without > rejects to a kernel prepatched with UML. > Even then, you have to redo the same work as for > the kernel-scheduler etc. Beyond all this problems, > the UML-RT-kernel wouldn´t be real-time capable any more. > > BTW: Everybody laughs about "printf-debugging" (means > writting message-bytes to the printer port), but IMHO, > for many hard-rt-applications(!) this is a quite > convenient way to get programms bug-free. > > Other possibilites: R2D2 from Zentropics and LXRT from RTAI. Alternative include 1. gdb which comes with RTLinux, 2. XBD the CAD-UL remote debugger for RTLinux, 3. CarbonKernel the RTLinux V3 emulation. -- - Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTLinux + UMLinux ???
Denis Karpov schrieb: > is it possible to run RTLinux in User Mode Linux I didn´t tried it, but it´s rather unlikly that it will run: the UML-Kernel is patched in the areas of memory management, process scheduling and interrupt-handling in order to be able to run as usual application. I doubt that the rtl-patch could be applied without rejects to a kernel prepatched with UML. Even then, you have to redo the same work as for the kernel-scheduler etc. Beyond all this problems, the UML-RT-kernel wouldn´t be real-time capable any more. BTW: Everybody laughs about "printf-debugging" (means writting message-bytes to the printer port), but IMHO, for many hard-rt-applications(!) this is a quite convenient way to get programms bug-free. Other possibilites: R2D2 from Zentropics and LXRT from RTAI. Bernhard -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTLinux + UMLinux ???
On Thu, Nov 02, 2000 at 03:56:01PM +0200, Denis Karpov wrote: > i have a question. since i'm new to RTLinux and kernel programming i > need some safe way to experiment with stuff. > is it possible to run RTLinux in User Mode Linux > [http://user-mode-linux.sourceforge.net/] > > that means one needs to apply UMLinux and RTLinux kernel patches > together > to 'straight' kernel source. is it going to work ? did any1 try it ? Don't know about UMLinux, but you might want to try user-level signals in RTLinux. The actual code still runs in kernel space, but you don't have to know nearly as much about kernel programming to use it. -- Nathan Paul Simons, Junior Software Engineer for FSMLabs http://www.fsmlabs.com/ -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
[rtl] RTLinux + UMLinux ???
hello, i have a question. since i'm new to RTLinux and kernel programming i need some safe way to experiment with stuff. is it possible to run RTLinux in User Mode Linux [http://user-mode-linux.sourceforge.net/] that means one needs to apply UMLinux and RTLinux kernel patches together to 'straight' kernel source. is it going to work ? did any1 try it ? rgds, Denis. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
