Slow Imaging Troubleshooting Guide
Article ID: 178415
Updated On:
Products
Issue/Introduction
Why is Imaging slow when deploying from the network
Environment
GSS 3.3
Resolution
1. Disable TCP Checksum Tx and Rx offloads on the server NIC
Right-click on Network properties/places.
Right-click on the Local Area Connection and select Properties.
Select Configure.
Select the Advanced tab.
2. Verify that the Speed and Duplex mode is identical on both the client PC (while it is booting into DOS) as well as on the Server PC. A mismatched duplex will cause extremely slow imaging or for the client PC to not connect to the Server PC at all.
3. Change the TCP Window Size on the Server.
This is a known issue from Microsoft and they have issued a KB article, which is located here: https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/description-tcp-features
4. Check and isolate your network configuration. If you have layer 2 (managed) or layer 3 devices in between your client PC and your Server PC, this may cause slowness completely dependent on the configuration of device.
a. It is recommended that the network be isolated to a simple layer 1 device such as a simple hub to isolate the network. You can still have an upload to the backbone.
b. Enable “Portfast” or its equivalent. Some routers and managed devices have different terms that mean the same thing.
5. Verify that you are using the correct drivers for your NIC.
a. Broadcom has issued a statement where the Broadcom B44 version “A” driver drops around one-third of the packets at the DOS level. There is nothing to be done about this at this time other than swapping out the Broadcom B44a NIC with another NIC.
b. Some drivers, although they load successfully and will map the network drive successfully will not have good throughput at the true DOS level. Please make sure that you have the latest driver for the NIC. An alternative is to use the UNDI driver if you are using PXE as your boot option. Using the UNDI driver will sometimes circumvent the driver as being the problem.
6. TCP Performance tuning in DOS
Summary:
When deploying an image to a DOS-based client via a mapped drive, one of the underlying protocols used to get the image file to the client over that mapped drive is TCP. The TCP parameter that controls how much data the DOS-based client can receive at a time is called the TCP Window Size. This parameter controls how much data can be sent to the client before waiting for an acknowledgement from that client that it’s okay to send more data. The default size for this window, if nothing is specified in PROTOCOL.INI, is 1450 bytes, which is the size of one network packet. This is the default for GSS and earlier releases. This means that for each and every packet sent to the client, the server must wait for an acknowledgement packet back from that client before it can send another packet. The higher the latency of the network, the more this will degrade speed. Increasing this parameter can dramatically improve performance for image deployment (not creation) especially on networks with higher latency.
One problem that may be encountered as this parameter was tuned is that Microsoft’s TCP stack can only take up to 64 KB of RAM including both code and buffers. These buffers are duplicated for every server connection that we can possibly make. This means that in order to increase the size of the TCP window, we must decrease the number of servers we can simultaneously connect to, or the TCP stack will run out of memory and refuse to load. If you only need to connect to one server, you can increase your window size more than if you need to connect to two or more servers. Please note that you can map multiple drives to shares on one server and all of those drives together only count as one server connection.
Below is a chart of parameter values we have changed to improve performance without running out of memory. Replace n with values contained in the chart. Use values across a single row together. Also below is a Microsoft Knowledge Base Article that discusses this in greater detail.
PROTOCOL.INI and TCPUTILS.INI values that we have tried:
|
protocol.ini [tcpip] tcpwindowsize=n |
protocol.ini [tcpip] nbsessions=n |
tcputils.ini [sockets] numsockets=n |
Number of servers you can connect to simultaneously |
|||
|
1450 |
(6.1 default) |
6 |
(6.1 default) |
4 |
(6.1 default) |
More than 3 |
|
2900 |
1450 x 2 |
6 |
(6.1 default) |
4 |
(6.1 default) |
More than 3 |
|
4350 |
1450 x 3 |
4 |
|
0 |
|
More than 3 |
|
5800 |
1450 x 4 |
4 |
|
0 |
|
More than 3 |
|
8700 |
1450 x 6 |
3 |
|
0 |
|
3 |
|
10150 |
1450 x 7 |
2 |
|
0 |
|
1 |
|
11600 |
1450 x 8 |
2 |
|
0 |
|
1 |
Microsoft KB Article : “Tuning TCP/IP for Performance”:
Feedback
