David Schleef said:
> Obviously, the probability of getting spinlock contention is very small
> on a quiet machine. On a machine that is using full bandwidth on both
> an RT ethernet interface and normal interface, you will get corruption
> and/or deadlocks _very_ fast. I've seen it happen reproducably in less
> than a second.
We must have the perfect test configuration. :) Our machine is configured
with 2
ethernet cards. eth0 is an eepro100, and eth1 is a tulip (DEC)
variant. We use the modified tulip driver on eth1 to talk to our device
at 800hz (from the RT task). On the non-RT side we have a process
listening to an RT fifo that receives the data at approximately 60hz and
sends it over
eth0 (via a SOCK_PACKET socket) to three other machines. eth0 is
running under the normal linux networking code drivers, and is unmodified
from a standard configuration. Now obviously our code needs to do the
"right thing"
and implement some kind of skb caching of it's own, and avoid the problems
associated
with the kernel. Admittedly, 60hz frames on the NRT side is no where near
"full bandwidth", either.
However, the above configuration has been running for 5 days now with no
problems,
as an FYI.
---
Michael M. Morrison
VP, Chief Technical Officer
Hyperion Technologies, Inc.
(970) 493-1900
--- [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/
