Image Deploy Rate Drop

JP, I don't know if you have this resolved or not but I would try Unicast mode when deploying, if you are wanting the fastest transfer speed. Take into consideration when using the Unicast mode, that the more machines that you attempt to image at one time, the slower the transfer rate. If you are going to image 12 machines at one time, Multicast mode is probably the better choice.

I saw this linked here in the forum by one of the moderators and maybe this explanation will help.

http://www.deploystudio.com/Forums/viewtopic.php?id=2083

Hello PatHarti,

The idea of multicast is not to race out the gate at maximum speed but to get to a secure cruise speed with as many machines at the same time as my network can host... View this as a 4 lane freeway vs. a 200 lanes highway. Freeway in concept looks faster but could get congested pretty seriously and highways (200 lanes doesn't really exist..LOL!) but will get a lot more people to destination at once and if we need to add more lanes there will be no impact on the overall time.

Sometimes for small files Unicast will do a better job than Multicast. For large files and many machines, multicast is the winner.

There are several technologies involve in both scenarios (Uni vs Multi) and they cannot be compared at all.

Unicast load and performance is driven by:

1- The network protocol being used like AFP, SMB or NFS. Whatever you are using the load is on the CPU of that server.
2- The NIC (Network Interface Card) on the server and on the client machines

Each client request the file and the speed is adjusted to whatever bandwidth is available in real time. It goes up and down all the time and can go to a halt if the number of requests exceed any of the above capacities. Of course it will slow down if the hard disks cannot sustain the initial rate. As more machines request a file , everybody slow down. You may be able to reach 65 to 100MBps with a single or few machines but this will drastically slow down if you do 20 and more.

That in a nutshell is pretty much it for Unicast.

Multicast in the other hand is driven by:

1- The Switch CPU capacity to copy and synchronize the packets among all the ports on the vlan.

The server will blindly transmit at the determined speed in DeployStudio assistant to the switch. Client machines will join the broadcast where ever it is in the process and start form there. There is little to no feedback provided to the server as to the status of the client. If a client drops too many packets a failed alert will be sent to the broadcasting server and depending on the status will either retry or totally fail and hang/crash/reboot.

TTL is the number of hup (switches/vlan) that the stream can traverse to reach it's final destination. You cannot set it to 0. Leave this to 3 unless you know for sure you have more.

On a good Gigabit network , secure stream speed will be around 15 MB and disk write 45MB. And of course on a 100Mbps well, you divide those by 10. There is no magic that can be done and these values are guidelines only. Your mileage will vary.

Hope this help you understand the differences.

-TP

"secure cruise speed with as many machines at the same time"

Hi Michael,
That's the weird thing, I was using Multicast and for a while the imaging process seems to run smoothly on a fairly consistent rate. The *.TIB image files are about 11GB. It was after the first 2 machines that completed that I saw the degredation. Could a Acronis service error cause the instability? I looked at the deployment logs of the jobs where I had clients that failed, and I saw this message consistently.

Error code: 1
Module: 52
LineInfo: 70E26A1BA387EA02
Fields: $module : "C:\Program Files\Common Files\Acronis\Agent\osd_server.dll"
Message: Client 'XXX.XXX.XXX.XXX' is not responding.

I did swap out the 10/100 with a 10/100/1000 Catalyst 3750 and I still saw the error above.

JP

It very well could. Have you tried contacting Acronis support using their toll free#?
I don't know if you have a test environment or not but have you thought about taking the imaging off of your main network and performing these tasks in a separte environment? This may produce better results for you, as you certainly won't suffer any major network degredation doing it this way.