On Wednesday 14 April 2004 11.11, David Olofson wrote: > On Wednesday 14 April 2004 09.47, Anders Torger wrote: > [...] > > > 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
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
