MS Scalable Network update

[Albuquerque]

Hey all,

About every quarter or so, I re-compile the company PE CD image with code updates, fixes, newer drivers and other new / improved features. For my next release, I'm doing some testing with the Microsoft Scalable Network update, which allows a ton of the TCP stack (more than you're getting with the current OS) to be offloaded to NICs that support the features. In combination with this integrated update, I also went through and downloaded all the newest and bestest Intel and Broadcom NIC drivers for the stuff we use in-house.

So I start testing. Works fine under VMWare Workstation 5.5, works fine on one of the Intel Pro/100 chipsets on an older Dell desktop, but my code breaks on a Thinkpad x41 tablet... The break came from a null return value from a WMI query asking which NIC I have installed. Normally a null value means I don't have a nic, but in this case, I know I do.

Sure enough, NETSTAT does indeed show I have a Broadcom B57 nic, I have TCP protocol bound, and I have the Microsoft client bound. But IPCONFIG returns a blank, and all the WMI entries are blank too. I downgrade drivers, use known-good drivers, and nothing works.

I return to a pre-MS Scalable Network update state and suddenly I'm back in business. ****

So I'm curious if anyone else has played with this, and if so, did you get it working? I think the stack offload could help a few of our machines that have the newer NIC's but less-than-stellar processor speeds, especially when performing a Ghost upload (compression soaks up a ton of CPU cycles, reclaiming a few extra from TCP overhead could definitely be a win)

The only reason I'm going down this road is because we're using gig links with the standard MTU value of 1500 and downloading images no less than 2gb in size, as well as uploading images in excess of 10gb in size. Obviously there's going to be a lot of TCP overhead in such a scenario, and since changing the MTU value doesn't seem to be an option (don't ask, ugh... ) then I'm looking for some other opportunities.

Thanks for reading...

[Br4tt3]

Hi!

We also use machines shipped with the new TOE (TCP/IP OFFLOAD ENGINE) NIC's. As a part of this to work we also of course needed to deploy the SNP pack to the servers and clients. However, I didnt include it in the WinPE image....

So far, I have seen improvments on large files when copied, however, it does not seem to do much for me when copying many small files. Also, as for now, the biggest win is for iSCSI devices we use! I will have a go on this one and see if I run into the same problems as u...

Just some info:

1. Which WinPE are u using? WinPE 2005 or?

2. Based on Win2003 SP1 or XP?

3. What does ur code do? what is it searching for?

NOTE: I have seen that the installation of the Broadcom drivers/app adds WMI instances when installed from within the full OS. I am using a Broadcom NIC, driver version 2.6.14.0...

[Albuquerque]

I'm using PE 1.6 based on 2003 R2. The code that's breaking is just a simple WMI query looking for an installed NIC so that I know I can continue. (No nic? Well, then there's no network functions in the menu...)

Removing the SNP "fixed" the issue, and also fixed the problem with a blank IPCONFIG too. Makes me wonder...

And regarding your performance findings, that's mostly what I would expect. Smaller files aren't going to have the continuous TCP overhead like one big huge hulking file... Since I'm transferring multi-gigabyte ghost images, I'd hope that some performance delta could be seen.

[Albuquerque]

I think I may have found the problem -- at least two of the necessary DLL files were not copied into the WinPE image. I integrated the package straight into my R2 distribution files, but PE by default didn't copy a few of the updates over. It may also be related to some missing NETSH components.

I'm building a new CD that contains all the appropriate DLL files along with all the NetSH components and will report back.

[Albuquerque]

Aha, that was indeed the problem. Anyone who is wanting to integrate this fix into their PE image, make sure you do the following:

• Integrate the SNP update into your raw OS files
  
• Edit the PE ODK extra.inf file, insert the following:
  

  [ExtraFiles]
  ;
  ; Following files were added for SNP support
  ;
  afd.sys=1,,,,,,,,0,0,,1,4
  w03a2409.dll=1,,,,,,,,0,0,,1,2
  wshtcpip.dll=1,,,,,,,,0,0,,1,2
  ;
  ; Following files were added for NetSH support
  ;
  netsh.exe=1,,,,,,,,0,0,,1,2
  ipv6mon.dll=1,,,,,,,,0,0,,1,2
  ipmontr.dll=1,,,,,,,,0,0,,1,2
  ifmon.dll=1,,,,,,,,0,0,,1,2
  ippromon.dll=1,,,,,,,,0,0,,1,2
  rasmontr.dll=1,,,,,,,,0,0,,1,2
  rpcnsh.dll=1,,,,,,,,0,0,,1,2
  dhcpmon.dll=1,,,,,,,,0,0,,1,2
  winsmon.dll=1,,,,,,,,0,0,,1,2
  aaaamon.dll=1,,,,,,,,0,0,,1,2
  hnetmon.dll=1,,,,,,,,0,0,,1,2
  fwcfg.dll=1,,,,,,,,0,0,,1,2
  nshipsec.dll=1,,,,,,,,0,0,,1,2

  
  

• Edit the PE ODK file Hivesys.inf, insert the following:
  

  [AddReg]
  ;
  ; TCP settings for TOE/RSS/TCPA offload functionality
  ;
  HKLM,"SYSTEM\CurrentControlSet\Services\Tcpip\Parameters","EnableTCPChimney",0x00010001,0x1
  HKLM,"SYSTEM\CurrentControlSet\Services\Tcpip\Parameters","EnableRSS",0x00010001,0x1
  HKLM,"SYSTEM\CurrentControlSet\Services\Tcpip\Parameters","EnableTCPA",0x00010001,0x1

  
  

That should do it. The NetSH pieces from the extra.inf are optional, but I chose to keep them because I can enable/disable TCP Chimney on the fly just to see how it works. And other functionality provided by NetSH is actually pretty nice; I hadn't been paying enough attention previously.