Hey Guys,

Does anyone know why i might be experiancing the following

I have 10 clients all DH61BE Core i5 identical, If i mulicast them from WDS i get 27% nic usage on the clients and if i multicast them from SCCM i get 4% nic usage, All default settings and servers exactly the same spec hardware and software running 2008r2,

However i have the following table

Im also getting hash errors from SCCM on my larger images, Just found the correct forums below is my older post.

http://social.technet.microsoft.com/Forums/en-US/configmgrosd/thread/d8931bc4-079d-40da-af1a-d5cca0e31b30/#b4eec319-1915-4660-a421-781e3f1287c6

What is going on I wouldnt belive Microsoft would release a product that gives me errors when deploying images on such a scale, However i have had IBM and Cisco come in and they have tested everything and as the above table shows its a SCCM specific issue.

I use Mcast as I work a a University and our labs are 100+ machines in each room

• Edited by Tim Jones AUT Wednesday, December 19, 2012 7:31 PM

ConfigMgr uses WDS for multicast so I doubt that the difference is directly related to that. It could however be a bug or some other incorrect configuration in ConfigMgr. I'd recommend you contact CSS directly to get support on this as every environment is different and frankly not that many folks have used multicast in ConfigMgr (2007 or 2012) suc

Tim, thanks for all the testing and research you've done around this.  I've noticed this performance hit too, but hadn't dug very deep.  Please post info when you hear back from CSS.

Hopefully we can get a blog post together that describes this, and push them to do a KB ar

No Problems,

I have yet to have time to open a call with Microsoft it has been really busy with BYOD Tablet strategies Windows 8 etc etc, 

However i do offer an update,

We scrapped Multicast for Unicast this year and did over 3000 machines via unicast and only took down the phone system once, However I have had a chance to revisit the situation

Updated SCCM to 2012 SP1 (obviously updating boot media to Windows 8 PE and Drivers)

Update DP to Server 2012 

Just tested today 

Default settings perform the same 1-3% network use on clients (30 in Multicast Group) however I have now applied the following in my environment 

Change Number 1

I have modified this registry value on Server 2012 I'm not sure that it still applies to this version (Server 2008 forum) however our network guys say we should set this anyway...... hmmmmm

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]

DWORD IGMPVersion and set it to one of the following values:

2 Support IGMP version 1

3 Support IGMP version 2

4 Support IGMP version 3 (default)

We have IGMP version 2 on our network (according to our NW guys so we have forced this to number 3 IGPMP version 2)

We also set the dword IGMPLevel to 2 (just to force the default we found the setting of 1 did not allow us to multicast at all it spent all day trying to open a connection). Found this here 

Change number 2

Registry keys under the WDS service I have changed these from the defaults in 2012  I dont use IPV6 so only changed the IPV4 values

tpExpWindowSize   = 2, tpMaxWindowSize  = 8,

Reduced MulitcastTTL to 5 this was at 32 which the Network guys suggested was far to high

Once i completed this Multicasting to the same 30 machines performance increased to 15% network utilization on the clients This was a nice increase and was completely useable for us in our environment I didnt receive any hash errors on my 47gb wim file when it decompressed either

Change number 3

Registry keys under the WDS service

ApBlockSize I increased this value to 4500 

Speeds increased on a multicast session of 30 machines to 20% network utilization on the clients

ApBlockSize I increased this to 7550 

Speed increased to 25% on the clients an acceptable level for us to begin further testing of SCCM Multicast

So....

All other settings are left default including TpCacheSize which is set in the 1100's on Server 2012 

Other things I have noticed, I have not received any hash errors on using server 2012 WDS multicast YET touch wood even using default settings 100% success all the time. However I have only imaged ~100 machines

My Server is in ESX5.1 now and has a 10Gb VMXNET3 and is on a different subnet to the clients

My Clients are 1Gb Intel Nics HP Enterprise boxs

There is 2Gb of bandwidth between the Server room and the building I am imaging in and 1Gb to the floor I am imaging on.

The switch I am on has a 1Gb uplink and 1Gb to each workstation.

The network graph from the Cisco Guys shows 300Mb/s average deployment speed

When I run 2 sessions of 30 I get 600Mb/s in total out of the server and 300Mb/s to each session so there may be even more I can push the system but for now I am happy as long as hash errors dont return.

Im using Scheduled Multicast 30 clients or time out of 5 minutes. Im keen to use Auto cast across our VLans so I will do some further testing later today.

Im not a Network engineer I dont understand the settings 100% that I have changed I also know our MTU is 1500 so this is possibly generating lots of fragmentation but IT WORKS for me and my 47gb Wim file..

• Edited by Tim Jones AUT Wednesday, May 01, 2013 4:10 AM
• Proposed as answer by PeteBC Thursday, December 19, 2013 9:04 PM

Yea contains all these apps dude, Our Computer Science and Mathematics teaching lab image (700 machines) im open for options on differnt ways of delivering these apps but there is so many components and issues with Databases and Services plugins and path issues with doing APPV etc

I'm also having multicast issues with server 2012 using MDT which uses WDS. In my testing using a legacy nic under hyper v improves multicast performance to 100mbps clients.

Network utilisation is alway 10% or lower; only with multicast traffic.

Using vmware workstation as the hypervisior enables 98% network utilisation.

ESX 5.1 using th Intel Desktop NIC with flow control is also using 80-90% network utilisation.

This is with a mdt server vm @ 10gbps a host @ 1gbps and client @ 100mbps.

It seems virtual nics without flow control cause the slowness. I used to have a server 2008 mdt server where we tweaked the registry settings and got 6000-7000kbps. All my testing is on a test network with a switch configured with IGMP v3 querier and listener. Also STP is configured.

You could try testing with the desktop nic in the vm on esx 5.1 and see if performance is improved. The physical network port needs flow control turned on as well.

• Proposed as answer by Matt-Wilkinson Friday, December 20, 2013 7:55 AM

Tim

Did you ever get an answer to your slowness issue? I am seeing the same issue where SCCM\WDS multicasting is much slower than MDT\Multicasting.

MDT\WDS Speeds:

SCCM\WDS Speeds:

I notice your clients have different nic speeds. In my environment we have 100mbps for all clients. 

We had to change the following key 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSMC\Protocol

TpMaxBandwidth"=dword:00000001

The default value is 100 . If your server nic has a 10gbps virtual nic this may "confuse" multicast. 

I think 

1 = 100mbps clients

10 = 1Gbps clients

100 = 10Gbps clients

Presuming you are using hyper-v for your SCCM DP.

Post what you find out. Of course every network is configured differently.

In my environment our DP's are virtual, but not in Hyper-V. We are using VMWare. I have adjusted the TpMaxBandwidth values from 100 to 1 and 10. Going to 1 the speeds jumped up to around 12\13\14 MB\s. When I went to 10, the speeds increased further to around 15\16\17\18 MB\s. Even with the increases speed here, I am nowhere near the multicast speeds of the MDT\WDS server. The difference between MDT\WDS server and the SCCM DP's is that the DP's are virtual and the MDT\WDS server is physical. I am beginning to wondering if the virtual platform layer is what is causing my problems.

TpMaxBandwidth set at 10

• Edited by Tony Chirillo Friday, January 09, 2015 10:26 PM

All of my DP's and the client I am testing with are both using the VMXNET3 network adapter, and I did verify with our storage admins that the ESX hosts are using flow control... We are still working a case with MS to hopefully get this figured out.

Hi Tony

We are experiencing almost the same issues as you, and it sounds like we have very similar configurations (our DPs are also using VMXNET3 network adapter etc.). The TPMaxBandwidth 1/10/100 reg values have exactly the same results as you are experiencing.

May I ask how you went with your MS case?

Thanks

Manny

Hey Manny!

I actually still have our case open with Microsoft. Still working with engineers to figure everything out. However, things are pointing to our virtualzation layer in our data center (I believe). For testing purposes, I stood up a physical DP in subnet "A" and conducted a multicast stream to some physical boxes in subnet "a". From testing with the physical DP, the speed definitely increased. Speeds were maxing out at about 20 Mbps once all of the machines were joined to the multicast session. There were some issues with the test machines joining the multicast session. More testing and troubleshooting will be done this coming week on the issue.

--Tony

• Edited by Tony Chirillo Sunday, February 01, 2015 1:19 AM

Hi Tony

Thanks for your reply. We've also been thinking about creating a physical DP to compare speeds. Your results are interesting.

We'll be doing some further testing this week, I'll post again if we find out something useful.

Cheers

Manny

Matt

What speeds are you seeing with multicast? We switched over to a physical DP to test and speeds jumped up to a 20 mbps average.  I am interested to hear what speeds you are seeing.  -Tony

We are still working on this issue. Microsoft did mention there is a bug when using a virtual server, and that a WDS registry setting needs to be changed.

TpMaxBandwidth"=dword:00000001 from 100

Doing so got us  much faster speeds that what we were seeing with virtual hardware, but still nothing faster than 20 mbs per second.

We switched to physical hardware, however we [including Microsoft] have not found a way to push higher network utilization. If seems that even on a 1 GB network, multicasting can not go faster that expected speeds on a 100 MB network.

We are still working on this issue. Microsoft did mention there is a "non-offical" bug when using a virtual server, and that a WDS registry setting needs to be changed.

TpMaxBandwidth"=dword:00000001 from 100

Doing so got us  much faster speeds that what we were seeing with virtual hardware, but still nothing faster than 20 mbs per second.

We switched to physical hardware, however we [including Microsoft] have not found a way to push higher network utilization. If seems that even on a 1 GB network, multicasting can not go faster that expected speeds on a 100 MB network.

• Proposed as answer by Tony Chirillo 12 hours 18 minutes ago
• Edited by Tony Chirillo 12 hours 11 minutes ago

We are still working on this issue. Microsoft did mention there is a "non-offical" bug when using a virtual server, and that a WDS registry setting needs to be changed.

TpMaxBandwidth"=dword:00000001 from 100

Doing so got us  much faster speeds that what we were seeing with virtual hardware, but still nothing faster than 20 mbs per second.

We switched to physical hardware, however we [including Microsoft] have not found a way to push higher network utilization. If seems that even on a 1 GB network, multicasting can not go faster that expected speeds on a 100 MB network.

• Proposed as answer by Tony Chirillo Wednesday, April 29, 2015 7:25 PM
• Edited by Tony Chirillo Wednesday, April 29, 2015 7:31 PM

Just wanted to update the thread.

With physical hardware, I am now getting around ~ 25% - 30% network utilization. I had to adjust the ApBlockSizeV4 in the registry. The default value 1373 and I am now using 7550. From what I understand is that Microsoft changed the default block size as part of Server 2012 to a smaller value so that multicast packets would not get fragmented. Microsoft did this based on numerous customer reports that their networks did not support packet fragmentation for multicast packets. This was done in response to customer complaints that networks cant handle multicast. In a nutshell, my network can handle the larger and fragmented multicast packets. Larger packet sizes are better for performance than smaller ones.

It would be nice to see if I could increase this further, but I have not identified a way to do so.

-Tony

• Proposed as answer by Tony Chirillo 12 hours 13 minutes ago

Just wanted to update the thread.

With physical hardware, I am now getting around ~ 25% - 30% network utilization. I had to adjust the ApBlockSizeV4 in the registry. The default value 1373 and I am now using 7550. From what I understand is that Microsoft changed the default block size as part of Server 2012 to a smaller value so that multicast packets would not get fragmented. Microsoft did this based on numerous customer reports that their networks did not support packet fragmentation for multicast packets. This was done in response to customer complaints that networks cant handle multicast. In a nutshell, my network can handle the larger and fragmented multicast packets. Larger packet sizes are better for performance than smaller ones.

It would be nice to see if I could increase this further, but I have not identified a way to do so.

-Tony

• Proposed as answer by Tony Chirillo Wednesday, April 29, 2015 7:30 PM