Multicasting speed issues
-
Having recently tried out 0.32 to the extent of taking an image of one PC and deploying it to another identical machine, I then tried multicasting the image to those same two machines.
Once started, the multicast process crawled along and estimated 5 to 6 hours for completion where as 15 minutes was about the time it took when I test deployed it to the single PC.
I had suspected our network as one machine was in the room next door. The Fog server and first PC were on net the same switch as each other but the second machine (next door) was connected via two switches. The subnet was the same for both locations.
I stopped the process and deployed the image via unicast to the first PC. This ran quickly, so I stopped the task and did the same for the second machine which (still connected via the extra two switches). This too ran quickly which I didn’t expect.
Any idea what I am doing wrong?
Many thanks,
Paul.
-
Check to see what kind of network appliances are set up, like printers and scanners and such. I’ve found leaving these plugged in while trying to multicast my lab makes my speed increase.
-
Also, if the switches are managed, ensure Igmp snooping is enabled and igmp querier is also enabled, this will restrict multicast traffic to just the members of the multicast session rather than every device on the vlan. The slow down could be, as mentioned above, a slow device which takes it’s time to drop packets that are not intended for it.
-
Jaymes/Lethal Kebab,
Being new to this system but based on your responses, am i right in saying that this uses a broadcast system, i.e. all nodes on the network receive the data rather than just the target PCs? I guess that would account for such a slow down. Currently our network infrastructure is about to be revamped. We have some managed switches coming into being as part of this with the idea that we can improve access to key servers etc.
As an experiment, I plugged the two test target PCs and the fog server into a small switch. We’re using our existing DHCP server rather than running this on the fog server so I started the multicast task then re-booted the PCs. Once they’d been issued with an address, I unplugged the switch from the school’s network and the multicast ran much faster. It was still slower than a unicast but certainly acceptable and miles faster than the rate I was getting beforehand. To that end quite possibly it could be a rogue device on the network causing the problems as you suggest.
One thing I noticed was the bandwidth usage seen on the fog server’s home page. With the multicast when connected on the school’s network, this hit the ceiling constantly rather than going up and down. When I looked more closely, I noticed that this ceiling was only 1MB/minute (?) where as during the unicast or multicast on what was effectively a private network, the ceiling was much higher.
Thanks,
Paul.
-
Your grasp on the broadcast system sounds right to me, I don’t honestly know much about that yet. But from your explanation that is the way that I perceived it, and turning off the devices or disconnecting them form the network had positive results.
I know that during a unicast the image is sent to the host and then decompressed. During a multicast the image is decompressed at the server and sent out to the hosts, so naturally it will be a bit slower.
The way you described imaging your two hosts, I imaged my labs this way. Our network here is in DIRE need of a revamp and I got the best speeds by putting the server on a cart and allowing the DHCP to issues addresses then disconnecting and imaging this way. It still only took ~ 40 min.
As for the ceiling on the graph, I can’t really answer that question, I didn’t pay much attention. I know for a fact that all my equipment is Cat6 and 1gb cards and I get some really good speed on 30-40 hosts at a time. I’ve never really paid much attention to the traffic
-
As I understand it, multicast is a form of broadcast which means that it will be sent to all nodes attached to that switch and on the same vlan.
What has an effect on speed is everything In between. Ie a cat 5 cable that snuck in there by accident, a FUBAR nic on one of the hosts etc etc.
IGMP allows the broadcast traffic to be directed towards those in the multicast session, rather than every device on the vlan.
After a switch upgrade, cabling and patching upgrade to make sure the lab was completely revamped, my multicast speed to 30 computers went from 500MiB/ min to 4.01GiB/Min.
The culprit was a dodgy patch on one of e hosts.
You can spend thousands on switching, but if you have a dodgy $5 patch, or a cat 5 cable in the mix etc, your multicast speeds will suffer.
