On Tue, 17 Dec 2002, Alain Knaff wrote:

...

I did so but it didn't help. What surprises me somewhat, is the fact the the performance is also very low for only 1 sender and 1 receiver. Here's what I tried:

Interesting...

From your previous mail, I see that there are retransmissions starting at 1.41. It might be interesting to experiment with smaller slice sizes (i.e. less than 40 packets), and half-duplex. With these settings performance would still be bad (40 packets are far too few packets for half-duplex operation), but probably not as bad as it is now: Performance around 10 Mbps should be possible (due to small slice size, latency probably wouldn't allow to go faster than this).

It might also be worthwhile experimenting with FEC. Performance around 40 Mbps (here, processing power of the CPU might be the limiting factor).

Another thing to try is to use the --max-bitrate flag to limit how fast the sender sends. Try limiting to 500 Mbps, and check whether this makes it faster.... It is possible that for some strange reason, attempting to transmit at full speed might overflow some internal buffers on the switch, causing it to drop loads of packets, which makes the transmission slow due to retransmissions (but should it make the transmission _that_ slow?).

Thanks for your help, I was able to improve the Bitrate to around 375 Mbps with the following commands:

Sender: time ./udp-sender --file /dev/zero --half-duplex --interface eth1 --max-bitrate 500m

Receiver: time ./udp-receiver --file /dev/null --interface eth1

I was able to maintain the performance up to 8 clients.

And, knowing that the problem can be reproduced with just two computers, you might try to link the computers with a cross cable, rather than the switch. At least, that will allow us to tell whether it is a problem with the switch, or with udpcast.

Since the initial problem seems to be solved I did not try this.

- Felix