Hello,
I've got problem with multicasting to many computers at once. I've got server with newest udp-sender (20071228) which is sending files from ext3 partition (with command ./udp-sender --pipe 'tar -B -S -cpf - -C /usr/share/systemimager/boot/i386/pjwstklenny .' --portbase 9006 --min-clients 2 --min-wait 15 --interface eth1 --max-bitrate 70M --mcast-all-addr 234.1.1.162 --ttl 10
and I'm trying to receive it with command:
./udp-receiver --portbase 9006 --nosync --ttl 10 --mcast-rdv-address 234.1.1.162 --pipe "tar -f - -x -vv -C /disk"
on client computer.
Problem is that, when I'm doing it one-by-one (I mean server-1 client) I get full speed - ~70MB/s, but when I'm trying to to this with >= 2 computers transfer drops to >0,5Mb/s. Why? I tried diffrent and the same subnet, I'm using 3com & cisco 3-layer switches (I also tried putting server and clients on the same switch - the same effect).
Please help, cause I've got >200 computers to clone ;)
Best regards
Paul Ufnalewski // BSS Polish Japanese Institute of Information Technology
Paweł Ufnalewski // BSS wrote:
Problem is that, when I'm doing it one-by-one (I mean server-1 client) I get full speed - ~70MB/s, but when I'm trying to to this with >= 2 computers transfer drops to >0,5Mb/s. Why?
This is most likely a switch issue. Many switches limit (throttle) multicast traffic, as they consider it "not important". Fortunately, this can be configured on most switches.
Another thing to watch out for is the lonely network printer (or other ancient device) that can't take data at more than one Mb/s. If you broadcast or multicast, most switches send out the data to all ports, and adapt the speed to the slowest device connected. Try to find out if that is the case by only connecting a bunch of "known-good" PC's to a switch (no uplink, no unknown devices).
Some high-end switches do actually understand the IGMP messages by which receivers inform that they are interested in the transmission. However, these devices are rare, and even if they do support IGMP snooping, it is often switched off by default.
Another thing you can try is switch off flow control. Some switches even allow to do this on a per port basis.
Regards,
Alain
None of this works for me. I think it's something wrong with ACKs from clients.
Alain Knaff pisze:
Paweł Ufnalewski // BSS wrote:
Problem is that, when I'm doing it one-by-one (I mean server-1 client) I get full speed - ~70MB/s, but when I'm trying to to this with >= 2 computers transfer drops to >0,5Mb/s. Why?
This is most likely a switch issue. Many switches limit (throttle) multicast traffic, as they consider it "not important". Fortunately, this can be configured on most switches.
But why when there's one client it goes full speed and when there are >= 2 it drops to 0.29? It's problem with unicast not the mulitcast.
Another thing to watch out for is the lonely network printer (or other ancient device) that can't take data at more than one Mb/s. If you broadcast or multicast, most switches send out the data to all ports, and adapt the speed to the slowest device connected. Try to find out if that is the case by only connecting a bunch of "known-good" PC's to a switch (no uplink, no unknown devices).
Tried that - only 1gb nics connected to 100Mb/s backbone.
Some high-end switches do actually understand the IGMP messages by which receivers inform that they are interested in the transmission. However, these devices are rare, and even if they do support IGMP snooping, it is often switched off by default.
It's on.
Another thing you can try is switch off flow control. Some switches even allow to do this on a per port basis.
Regards,
Alain
Paweł Ufnalewski // BSS wrote:
But why when there's one client it goes full speed and when there are >= 2 it drops to 0.29? It's problem with unicast not the mulitcast.
Indeed, in one case, it's unicast, and in the other it is multicast. If there is only one client, the sender falls back on unicast, which is handled much better by most switches.
[...]
Tried that - only 1gb nics connected to 100Mb/s backbone.
^^^^^^^^^^^^^^^^^^^ Please do try it with only 3 PC's (1 sender, 2 receivers) connected to the switch. Nothing else. And I do mean, nothing else (well, except the power, of course...). And from there work your way upwards until it becomes slow. Indeed, as soon as a switch is connected to another switch (uplink, backbone, ...), it also becomes vulnerable to whatever else is connected to that other switch (flow control propagates, unfortunately). I know, it does take some patience, but AFAIK, this is the only way to find out what is triggering the slowdown.
Regards,
Alain
-
Alain Knaff -
Paweł Ufnalewski // BSS