14 Apr
2004
14 Apr
'04
8:26 a.m.
On Wednesday 14 April 2004 11.11, David Olofson wrote:
On Wednesday 14 April 2004 09.47, Anders Torger
wrote:
[...]
I think I can get away without the real-time OS, using just plain
rt-scheduling in vanilla Linux. I do not need extremely low latencies,
I can tolerate quite high I/O delay. The processing block size will be
at least 512 samples (2048 will probably be the normal size), and the
I/O delay through the system is allowed to be more than two blocks, if
I get below 250 ms in the system I outlined I would be satisfied.
What I see as the main problem is acheiving the high throughput without
packet loss, and with a stable latency. But I guess as soon as I start
testing (if I do, it is just a fun idea for the moment) I'll come
across lots of interesting problems. I don't know of anyone that has
tested streaming say 300 uncompressed channels in parallel...
/Anders Torger
Thus, I think it is necessary to implement
something operating on
the ethernet level to get best performance in terms of throughput
and latency.
Sounds like you'll need something like this:
* A real time operating system
* Decent ethernet hardware (most 100+ Mbit h/w should do)
* A protocol stack with RT streaming support. (Or
implement your own protocol, using the ethernet h/w
as high speed serial ports/bus interfaces.
* A distributed hard RT application