MultiCast very slow

[plegrand]

Now, just to see if multicast is the issue, can you multicast to just two computers? Make a temp group, put two computers in it, and then use that group to multicast. Is there a speed difference?

I’ll make the test

Also - the switch is important when multicasting.

It 's Alcatel switch OS6250 and OS6450 configured like that : http://plegrand1.free.fr/pasted_image001.png
I’m not sure if the configuration is ok
Thanks for your help

[plegrand]

@Wayne-Workman Hello
just for information :
On my switch i configure (force) the igmp version to “3”, may be i should use the default version : “2” ?

An other question : i thought that fog used “udpcast” for multicasting, is it true ?

[Wayne Workman]

@plegrand said:

On my switch i configure (force) the igmp version to “3”, may be i should use the default version : “2” ?

Try it and let us know. at this point, anything that causes a change is good.

An other question : i thought that fog used “udpcast” for multicasting, is it true ?

I think fog uses udpsender.

[JJ Fullmer]

@plegrand A couple questions
What are the specs (cpu(s) model and speed, Ram speed and size, virtual/physical) of your FOG server?
What are the specs of the workstations (specifically the slowest one)?
What is the compression rating on the image you’re pushing?

Something to understand about multicast (and someone should correct me if I’m wrong) is that is does all the decompression on the server and then sends the packets out following multicast protocol. The idea of multicast is to do more on the server side and less on the client and get a constant speed. It also is meant to prevent using a file or part of a file that is in use to make a fail safe against corrupting files and such. The downside is that if you’re using an image with a compression level of 9 and your server isn’t all that powerful, multi-cast is going to slow down a lot compared to unicast where decompression is done on the client.

My point is if your server has less power or less optimization for decompressing then your clients, multicast will just be slower. Considering your speed difference of multicast and unicast, my guess would be this is the case.

Also, a side note in favor of just using unicast, I have used fog to deploy to a lab of 40 computers (10 at a time, which can be changed with the Max clients setting in the storage configuration, just fyi) with the same image on unicast and had no problems with corruption and the speed was glorious.

Another limiting factor is client and server port speeds. If your server is on a 10/100Mb port, you should upgrade that because it will make your life painful. But if your server is on a Gigabit switch then 10 clients on 100Mb switches will all run at around 1.7 GB/min (estimated mathematically and based on experience) If everything is on gigabit switches/ports then you might see a decrease in client speed as you add more simultaneous clients , but will still be around 2 or 3 times faster for 10 clients. Just to give you a little reference off the top of my head.

It would probably be a good idea to start recording average speeds for common configurations and post them in the forum somewhere so people have a reference of how fast to configuration ought to be performing.

[Wayne Workman]

@Arrowhead-IT said:

Something to understand about multicast (and someone should correct me if I’m wrong) is that is does all the decompression on the server and then sends the packets out following multicast protocol.

That’s wrong, multicast sends the data compressed just like unicast deployments do. Decompression happens on the client side. And the idea of multicast is to broadcast throughout a broadcast domain, in order to send data only once instead of many times. There is a lot of overhead with multicast, but the more clients that are receiving the stream, the bigger the payoff.

Don’t feel bad - I thought the same thing, but tom corrected me then as I am now for you. The post is somewhere on here - from maybe a year ago lol.

[plegrand]

@Arrowhead-IT
lscpu
Architecture : x86_64
Mode(s) opératoire(s) des processeurs : 32-bit, 64-bit
Boutisme : Little Endian
Processeur(s) : 8
Liste de processeur(s) en ligne : 0-7
Thread(s) par cœur : 2
Cœur(s) par socket : 4
Socket(s) : 1
Nœud(s) NUMA : 1
Identifiant constructeur : GenuineIntel
Famille de processeur : 6
Modèle : 30
Nom de modèle : Intel Xeon CPU X3480 @ 3.07GHz
Révision : 5
Vitesse du processeur en MHz : 3059.238
BogoMIPS : 6118.47
Virtualisation : VT-x
Cache L1d : 32K
Cache L1i : 32K
Cache L2 : 256K
Cache L3 : 8192K
Nœud NUMA 0 de processeur(s) : 0-7

free -m
total used free shared buffers cached
Mem: 32233 1192 31040 23 196 624
-/+ buffers/cache: 372 31860
Swap: 65514 0 65514

df -h
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/sda1 8,2G 1,2G 6,6G 15% /
udev 10M 0 10M 0% /dev
tmpfs 6,3G 8,6M 6,3G 1% /run
tmpfs 16G 0 16G 0% /dev/shm
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 16G 0 16G 0% /sys/fs/cgroup
/dev/sda5 2,7G 445M 2,1G 18% /var
/dev/sda7 360M 3,8M 334M 2% /tmp
/dev/sda8 842G 25G 774G 4% /home

eth0: NIC Copper Link is Up, 1000 Mbps full duplex
eth1: NIC Copper Link is Up, 1000 Mbps full duplex

I made a test : Multicast and unicast 12 stations

**Multicast **=> 04h 40min
**Unicast ** => 28min

[JJ Fullmer]

@Wayne-Workman I wonder if I got compression part from that post a year ago. Some of that is what I remember from my college Networking class.

@plegrand Looks like the problem shouldn’t be the server power, and I was wrong about that part anyway.
Considering the speed difference you already are seeing, why not just use unicast? I’m just curious if there’s a specific requirement for multicast?

[Sebastian Roth]

@plegrand Any news on this? Do you still see slow speeds when using multicast?

[plegrand]

@Sebastian-Roth Hello
for the moment i didnt make any test about multicast.
But it’s planed
I will tell you
I have to look on switch configuration

[czajne]

This post is deleted!