[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [linrad] Second operator
- Subject: RE: [linrad] Second operator
- Date: Sun, 23 Mar 2003 15:14:55 +0100
Hi Edson and All,
> It is nice to see Linrad starting to leverage multiprocessing over a
> network. The word "cluster" comes to mind!
> You may want to use UDP sockets instead since they do not need to have a
> connection established. I have done something similar to what you have
> described. The difference is that I broadcast packets with the raw PCM
> data over the local area network and let the client PCs take care of the
> Fourier transforms. Using the broadcast address, all computers on the
> same LAN can hear the same packet. Since no connection is involved, there
> is no guarantee that the data will be delivered, but if the traffic on the
> LAN is low, this is rarely a problem. What I do to detect packet loss is
> to reserve the first byte of every data packet for a counter that is
> incremented by one on every packet sent. The receiver can keep track of
> this and signal any packet loss. If the traffic is high and there is
> packet loss with conventional half-duplex Ethernet hubs, you can solve the
> problem by using a full-duplex Ethernet switch.
I made some quick tests and found difficulties. Maybe the slow computer
can not buffer up enough data when it arrives in big chunks over a 100
The data rate is 96kHz * 4 * 2.37 * sizeof(float) = 29 megabit/second
for fft1 output with a sin^3 window. To make the program flow easy
within Linrad I just write a complete set of transforms each time
it is produced which means that the system has to buffer up something
like 262 kilobytes for each write with 15 writes per second or so.
I have decided to not go deeper into this for the moment so I have
uploaded linrad00-55 which works with AF_INET and SOCK_STREAM.