Last edit: Peter Favrholdt on July 1, 2006 23:23 (5195 days, 5 hours and 29 minutes ago) (diff)
Rtai.Dk | RecentChanges | Preferences | DIAPM RTAI

When selecting Hardware for RTAI, you need to be careful. Not all PCs are suitable for hard realtime applications. The primary concern for this is not the "speed" (GHz etc) of the hardware, but its maximum latency.

You can look at List of compatible hardware and List of problem hardware in this wiki to coose your hardware. You should also try [An RTAI 3.1 LiveCD with WebApp]. There you find a hardware database and a LiveCD to test if your hardware would work.

The stuff below is from the mailinglist. Please revise!

... forgot to say you did not mention the chipset in use. I've recently used a GigaByte? dual PIII MB (VIA chipset) and was OK, so I did not care. In any case I took a further look and it seems it uses Intel 845. All MBs using Intel 845/850 tested at DIAPM have shown problems, also below 2.2 GHz. Just to report DIAPM experience, till now we had no problem with VIA and SYS chipsets, both for INTEL and AMD CPUs....

To see if you have bad hardware use the buslck example program - here is the README:

"****** BUS LOCK CHECK ******"

More and more motherboards are being sold that have some optimizations at the bus level locking the bus, maybe up to few millisecs. Even without judging if such a way of working is acceptable, maybe it makes it appear to improve overall average performances in general applications, it surely dooms real time usage. What RTAI users see are large scheduling jitters and they start hinting at bugs that likely do not exist. This check is aimed at helping in tracking such a problem. It measures interrupt latency by using the TSC on the timer interrupt, machines without it do not have such a problem for sure. The only module implied is rtai.c, there is thus no scheduling but just interrupt dispatching, that should have latencies in the range of 20/30 us worst case. So if you'll see something too much higher play with its configuration parameters, with those of Linux as well, to end in buying another board eventually. Excess latencies are echoed from within the interrupt handler directly when a certain threshold is exceeded. It can be set by the user by changing the macro THRESHOLD, in nanos. The timer inturrupt ticking is controlled by the macro PERIOD, in nanos. It is possible to check it also on a scope by defining the macro PARPORT, that sets the address of the parallel port, see the code.

To run it do: make clean make ./run

Subject: Re: Why is my real-time task getting pushed around?
Date: Wed, 19 Mar 2003 23:29:44 -0500

Hi Steve,

Thanks for your reply.  Since my post I have done a lot of work trying to
understand what is going on.  I've made some progress and while my research
is not complete I'll share what I (think) I know.  :-)

In the case of the i845 chipset that's on my Tyan Tomcat motherboard, the
problem is not "bus locking".  It is power management.  Or, more
specifically, SMI (system management interrupts).  In a real time
environment, SMIs are evil.  First off, in my sytem they last about 200
microseconds, which, for me, causes unacceptable jitter.  Second, they are
the highest priority interrupt in the system (even higher than the NMI).
Third, you can't intercept the SMI because it doesn't have a vector in the
CPU.  Instead, when the CPU gets an SMI it goes into a special mode and
jumps to a hard-wired location in a special SMM address space (which is
probably in BIOS ROM).  This is why RTAI can't help -- SMI interrupts are
essentially "invisible" to it.

According to the ICH4 (that's the main controller chip) spec, it is possible
to disable SMI interrupts.  The ICH4 has all its registers mapped to I/O
space so it's just a matter of calling "outb" from your module.  In my
system, I have used the following calls to disable SMI:

outb(0x08, 0x469);  /* Disable watchdog timer in the ICH4 */
outb(0x3a, 0x430);  /* Clear the GBL_SMI_ENA bit */

So far, it seems to be working and my jitter is in the 10's of microsecond
range, which is much better.  I still need to do a lot more testing to
verify that this is all I need to do to solve my SMI problems, but it looks
good so far.

In response to your buslocking comments, I agree that other DMA devices in
the system can be thought of as "multiprocessors".  However, in most cases,
the hardware in the system "plays nice" and the PCI bus is so fast that any
sort of "buslocking" that may occur is probably minimal.  Of course,
"minimal" depends on how tight your real time requirements are.  :-)


Edit text of this page | View other revisions | Download Rtai.dk