[quote=“Wayne Workman, post: 44225, member: 28155”]I think one of the biggest core-problems with I.T. support people multicasting is being unable to access their switches / routers.

These dumb barriers between network teams and I.T. support are created. A technician will say “Multicast isn’t working”, network admin says “It’s set up, you must not be doing it right”… vicious circle. And that’s if they even BOTHER to help you… Either person could be wrong, honestly. But, without one being able to see the other’s setup (or communicate really well), it’s pretty pointless to even try to troubleshoot.

I despise things like this.[/quote]

After being told by our network group that multicast was enabled on the production switches on Monday, we found out yesterday that only one of the two switches supports layer three. The ports in the labs are randomly patched into the switches, no documentation. Wire rack is locked, etc…

Ran another test this morning. 15 thin clients using production switches. Start the multicast, all systems pxe and sitting on gray screen. Multicast not starting. Go into the task list the ones in the group that are ready are patched to level three multicast. The ones that are still connecting were patched to the layer two switch. Made bets with network guys. Killed task. Created a new group with thin client members that were waiting in the first job (six computers). Started multicast, executes perfectly. I’m very lucky to have had the fog server randomly patched into the switch with layer thee capabilities. I had given up on multicast last summer.

Four years I’ve been using FOG now, always hear it from the networking group that there is nothing wrong. But they put in all into emails so now it is documented. Getting my own switches this summer.

126GB in 23 minutes is just shy of the 20 minutes (the fastest it could go), the only limitation for the multicast was the GB network cards.

Now if I can figure out the TFTP Boot errors…

Just my 2 cents on Multicasting issues. I use fog to image two labs at SCSU. Multicast never would work. Last week was spring break I had the time to run a couple of tests. I followed all the instructions to test multicast on the forums but multicast deploy would hang on the blue screen and that was that. I do not have administrative access to the production switches.

Images are complex with ubunutu with many VMs in the images. Image type; RAW, compression is set to 3. Client hardware; HP Thin Clients with 8 GB of memory and 126GB SSD.

Fog Server Dell 6GB. I do have a HP on the way in a month that will have 64GB to test at the end of spring semester so I may be able to speed thing up a bit.

I decided to swap out, (our office of information technology Cisco managed switches) with Cisco SBM switches out of the “box”.
Multicast in Fog works just fine.

I tested the following:
Multicast 8 HP Thin Clients on Cisco SMB Switches - average image 22 minutes.
Multicast 15 HP Thin Clients on Cisco SMB Switches - average image 26 minutes.
Unicast 8 HP Thin Clients on Cisco SMB Switches - average image 1hr 26 minutes.
Unicast 15 HP Thin Clients on Cisco SMB Switches - average image 2hr 54 minutes.

Unicast to 15 Thin Clients on production switches to 15 systems would vary from 2 to 4 hours.

I do multi partition non resizable NTFS 40GB images and this averages 24 minutes unicast. I did not have time to test this in multicast.

So multicast does work and for larger deployments is much faster. Performance is 23 minutes vs 1hr and 26 minutes. I have sent the fog logs to our OIT group to have them look into their Cisco’s. I am planning to replace the current production switches . I would suggest to add a line to the testing of multicast to just swap out any old switches.

[quote=“Steven B, post: 37172, member: 24174”]I’m running fog and imaging a bunch of HP t820 with 128G SSD drives. They are linux based so the up / down is raw not resizable. I can do on one system in about 15 minutes averaging 7G on the push down. I was able to push 16 systems last week and averaged 4.6G This week the 16 systems thru put drops to about 1G to all.
Similar thru put to traditional window systems but because nfts performance is better. Monitoring the eth0 now to see. I may have issues with the universities network getting udp traffic to and from other ips.[/quote]
No the server is not SSD. The ubuntu image has four VMs with networking. I have 3 SSD drives in the thin client. 16G windows 7 for horizon view 80G with dual boot windows 8 server 2008.

[quote=“Frank D., post: 36429, member: 26015”]I also got multiple Optiplex 3020. The ones with a normal HDD are working like a charm with FOG (1.2.0).
But we also got some Optiplex 3020 with a 128GH SanDisk SSD (straight from Dell), and uploading an image on this type of 3020 is not possible. The task keeps hanging on : "Using Hard Disk /dev/sda ", and nothing further happens (same problem as topic).

Anybody got an idea? I’ve tried almost every kernel available. Image is a Windows 7 enterprise image.

Grtz Frank.[/quote]
check the bois. I make the other dives not discoverable and it should work.

[quote=“VincentJ, post: 36878, member: 8935”]Not exactly solving the problem of the slow speed, but could you do twice as many with an extra storage node?

I’ve found with multiple clients there is a point at which the slowdown really does ramp up. would be interesting if someone had FOG on SSD and could see if the same thing occurred.[/quote]

I’m running fog and imaging a bunch of HP t820 with 128G SSD drives. They are linux based so the up / down is raw not resizable. I can do on one system in about 15 minutes averaging 7G on the push down. I was able to push 16 systems last week and averaged 4.6G This week the 16 systems thru put drops to about 1G to all.
Similar thru put to traditional window systems but because nfts performance is better. Monitoring the eth0 now to see. I may have issues with the universities network getting udp traffic to and from other ips.