On Wednesday 25 July 2001 15:02, Dan Morrill wrote:
> Our application must process messages generated from various
> network nodes and transmitted over Ethernet.
>
> We have calculated that we will have 57,600 messages per second,
> at 368 bits per message. We're using raw Ethernet frames (no TCP/IP.)
> This comes out to 21,119,800 bits per second -- i.e. around 20MBit/sec.
>
> We're using a 100bT Ethernet LAN, so the raw bandwidth (we think)
> should be under control. However, each of these 57,600 messages must
> be actually processed by various (generally small) "protection
> algorithms." Most messages require no response but some may indicate a
> fault and need to be responded to.
>
> We're currently attempting to do this on a 1000MHz Pentium III box.
> Turnaround time for any given message that requires a response can
> be no greater than 2 milliseconds. (It occurred to me the other day
> that we are more or less being asked to build an oscilloscope that
> listens over Ethernet. :)
>
>
> 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? :) Any suggestions or pitfalls? ("You
> need a dual processor box." "Don't shoot yourself in the foot by doing
> Foo.")
Well, 2 ms is a loooong time around RTL, but do watch out for requests
queueing up! If possible, just respond to incoming messages ASAP when
needed - less overhead and no risk of overflowing some FIFO or running
out of message structs somewhere between a receive and a transmit thread.
If you need the buffering to be done on that level (does increase
throughput in some situations; required unless you can generate any
response in bounded and sufficiently short time), try to keep the number
of dependencies (locks, blocking on various "provider" threads etc) low,
and if possible, calculate buffers/pools and timeouts so that it's
impossible to over/underflow.
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
(so one response can block without stalling the entire queue), perhaps
using one thread per response (using a thread pool, perhaps), or one
thread and one queue per "response class".
//David Olofson --- Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------> http://www.linuxaudiodev.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`--------------------------------------> [EMAIL PROTECTED] -'
----- 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/
