Hmm. I'm somewhat concerned about an apparent attitude of... - if the hardware does "X" (e.g., PCI stalls), the software can't do anything about it Yet the example of X and "non spec" cards appears to be part of a problem that a real time developer needs to... - know about and understand - the software COULD do something different that didn't cause the problem to begin with As a system designer, I want to know where the "oopses" are and avoid them. In our case, we weren't planning on running X anyway, but we might have similar problems with network I/O, the cluster interconnect, and some occasional disk I/O. Are there some things we should look for and avoid for those cases? We're looking at a cluster of machines to run a real time simulation (fastest rate 80hz). Its a large system that we are unwilling to run in kernel mode. Our system needs relatively low latency and jitter. However, for most of our code, a millisecond here or there isn't a big deal. For a couple specific hardware interfaces - we have an exceptionally tight tolerance (+/- 50 microsecond jitter on data transfer, 80hz rate). We'll use a hardware assist for now - perhaps a kernel RT task later. The solution we're looking at today is a combination of... - low latency patches to Linux - some form of "user land" RT for most of our tasks (RT_FIFO, LXRT?) - a few items [TBD] to be under RTLinux, ADEOS, or similar product >From what I've read in the ADEOS docs doesn't help much over what RTLinux does today other than avoid the patent [which does have value to us]. What we'd prefer to see more focus on good performance in user mode and still have access to non-blocking Linux services. I see most of the solutions suggested to date are unable to meet that need. --Mark H Johnson <mailto:[EMAIL PROTECTED]> Karim Yaghmour <[EMAIL PROTECTED]> To: Cort Dougan <[EMAIL PROTECTED]> Sent by: cc: William Montgomery <[EMAIL PROTECTED]>, owner-realtime@realtim [EMAIL PROTECTED], [EMAIL PROTECTED] elinux.org Subject: Re: [realtime] Re: [ANNOUNCE] Adaptive Domain Environment for Operating Systems 02/16/01 04:51 PM Hello Cort, You're somewhat right. There are hardware issues that may be out of the reach of any software, the PCI stall example is a good one. On the other, whether RTLinux is running on Alpha, MIPS or PowerPC, device drivers can still issue the equivalent cli/sti and ruin determinism. There's nothing RTLinux can do about it. Best regards, Karim Cort Dougan wrote: > [snip] > Current versions of X (4.x) are pretty aggressive with cards that are not > entirely spec which results in PCI stalls. That's a problem for any > real-time system since software can't do much about this once it's > happened. -- [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/
