I'm running a rather CPU intenstive RTLinux application for realtime control, using RTLinux release 9H with the 2.0.35 kernel. The general setup is that a periodic IRQ (DAQ board generated) triggers the acquisition and control routine, and a fifo is used (serviced by a fifo interrupt) for the occaisonal command sent to it. When I am running at very high rates (where RTLinux is using >75% of the CPU time), I sometimes find that FIFO messages get "dropped" -- they never are detected by the RTprocess. This condition eventually clears itself, but the dropped messages are never recovered. I have two questions: 1) Has anyone seen anything like this? 2) Is it possible to set a priority level to both the to the various RTL interrupts (FIFO,hardware,periodic)? It has been fun to see how fast I can push our system. At 40kHz, I can still run X. At 80kHz, X is unusable, but a console mode interface still works, although the printing of text is slowed and it looks like an old 110bps modem connections :) -- Rob Butera, Postdoctoral Fellow http://mrb.niddk.nih.gov/butera/ Laboratory for Neural Control, NINDS National Institutes of Health, Bethesda, MD USA --- [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/
