Mavericks Server Deploy Studio Multicasting tests

I read the wiki page on multicasting from the Deploy Studio wiki pages.

When I'm imaging one machine, I'm getting a download rate of 8.5MB/s, and a variable write rate, but it is a compressed image. When I put 5 machines on, I'm getting about 1MB/s download rate, which is too slow for my liking, especially with a 89GB Image file.

The server is a new (2014 - July) mac mini server, 8GB RAM, 2 x SSD 256GB, Mirror RAID. Deploy Studio 1.6.11

Repository is stored on another server, on a different subnet which might cause issues? Shared via CIFS.

The Server is on GigaBit LAN so I'm trying a 10MB/s stream rate to start with.

The computer suite I'm testing on are Mac Mini's from 2011, 4GB RAM, 500GB SATA HD's.

To get the Client Write Disk Speed I put in this command in the terminal:

sudo dd if=/dev/zero of=/tmp/test bs=1024 count=1048576
Password:
1048576+0 records in
1048576+0 records out
1073741824 bytes transferred in 18.062331 secs (59446470 bytes/sec)

This converts to 59MB/s

Test 1

clients: 5
Stream Data Rate: 10MBs
Client Disk Speed: 43MBs

Conclusion: Got about 20 fails on each computer before 2% of a 89GB compressed image.

Realised I didn't scan for restore. At this point I scanned the image for restore using Disk Utility on Server.

Test 2

clients: 2
Stream Data Rate 10MBs
Client Disk Speed: 42MBs

Conclusion: Got about 7 fails on both machines before 2%

Test 3

clients: 16
Stream Data Rate 6MBs
Client Disk Speed: 38MBs

Conclusion: Got 2 fails in the first 2%, but 7 more fails in the next 6%. Interestingly, 7 out of the 16 started doing the recovery partition first, and as it was so quick, got onto the main image after the rest were over 2%. This might explain the packet loss. Getting a consistent 13 fails per 8%. Not sure if this works out at less then 20% or more? Seems to have failed to reimage 3 out of 16, which is good.




For the next test I wanted to see if having the images on the server itself would speed things up. I setup the repository in NetBootSP0 in /Library/Netboot/NetBootSP0

Test 4

Clients: 4
Stream Data Rate 6MBs
Client Disk Speed: 38MBs

Conclusion: 1 machine out of 4 got 20 fails before 2%, but then only got 2 more for the whole restore. Must have been a network spike or something. The others report very little (smallest so far) fails! Yay. Think I'll try and speed it up for next test.

Deploy Studio RC20 MultiCasting on OS X 10.4.11 xserver

After finally finishing the Master image it came in at 72GB! Takes about 3 hours to image one machine and 6 hours for two. So I thought I'd give Multicasting another go (I tried it a couple of years ago with lots of lost packets!). Also just heard they refitted the server room so maybe this'll help.

It was set up a few months back when we had DHCP problems caused by upgrading DeployStudio to RC20. You get the option to set up Multicasting when you set up DeployStudio Server. Here's my post

So taking a new iMac 24" and an old white 21" iMac I thought I'd set up Multicasting. First in DeployStudio admin I clicked the image and clicked the Multicast button at the bottom (looks like the Airport icon)

Airport Icon at bottom denotes MultiCasting

This now shows it's multicasting in the Activity section.

I've set up a workflow to restore an image to a volume, and in this set up some Multicast options.

Setting up Multicast options in a workflow

So far I have tried:

• Attempt 1
• Stream Rate 6MB/s
• Clients Disk Speed 120MB/s (I wasn't sure about the older 21" iMac so I slowed it from 200MB/s)
• Start Trigger 2 client
• Result:
• Stream Rate 5MB/s
• Disk Rate changes from 5MB/s to 15MB/s

I've been writing this as the process is going, and just noticed at 12:48 that some errors occurred. I noticed that this happened around the time that I loaded DeployStudio Admin on my machine, so I think this might have caused a slight interruption on the server (and it is 7 years old now). I do remember that I once remote'd into a machine whilst imaging which interrupted it. So the process is a little delicate. I shall wait to see if it has effected the process or whether it can cope with a few byte missing here and there?

After waiting until the 100% marker (which took 3 hours) it seemed to have stopped with no more errors, although it didn't quite finish. It said something about "starting" but just stopped there. I waited for another hour with no more progress so decided to reboot. Upon reboot the startup disk was not set, and the came up with the white screen with a question mark!

My initial conclusion was that the process had failed, but in hindsight I think that maybe the computers were waiting the data that was lost to be broadcast again, but this might be me clutching at straws. I shall look into it at the end of August. For now we'll just have the old method to use.