On Wednesday 25 July 2001 11:30 am, David Olofson wrote:
> On Wednesday 25 July 2001 15:02, Dan Morrill wrote:
> > This is just a general question; I'm attempting to draw on the
> > expertise of the group. Do we have a snowball's chance in Hades of
> > pulling this off w/ RTLinux? :)
> Well, 2 ms is a loooong time around RTL, but do watch out for requests
> queueing up!
Yes, that's our strategy. We're looking at optimizing the architecture
of our code to make sure we don't have any bottlenecks. Get the data
from ethernet stored as quickly as possible, "triage" it, and handle the
highest-priority messages first.
The 2ms is more than enough time for any given message, but as you
point out, the trick is to keep up with ALL the messages!
> Also make sure it's not possible to get trapped in a situation where one
> late response delays all responses following it in the queue. If the
> responses depend on various other threads and/or may take "long" to
> generate, it might be necessary to run the response handling in parallel
Fortunately, our algorithms are fairly small. Generally they just involve
performing some check or numeric computation and making an
appropriate reaction. (Usually a response message back out over
ethernet.) However, these algorithms may involve FP computations,
which introduces some obvious problems. Our algorithms are small,
but are they small enough? I'm thinking that's what's going to make or
break us.
At any rate, I didn't hear anything like "57,600 messages a second?!
Sucks to be you." That's encouraging. :)
Thanks for your reply!
Dan Morrill
Computer Scientist
GE Corporate R&D
----- End of forwarded message from [EMAIL PROTECTED] -----
-- [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/
