Sorry for the long append, but here is an excellent explanation of the
subject courtesy of Charlie Nichols, one of our performance guys...
For starters, I include some relevant sections from the Microsoft Windows
NT 3.5/3.51/4.0: TCP/IP Implementation Details document available from
their web site:
------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------
TCP Receive Window Size Calculation
TCP Receive Window Size Calculation
The TCP receive window size is the amount of receive data (in bytes)
that can be buffered at one time on a connection. The sending host can
send only that amount of data before waiting for an acknowledgment and
window update from the receiving host. The Windows NT 3.5x/4.0 TCP/IP
stack was designed to self-tune itself in most environments. Instead of
using a hard-coded default receive window size, TCP adjusts to even
increments of the MSS (maximum segment size) negotiated during
connection setup. Matching the receive window to even increments of the
MSS increases the percentage of full-sized TCP segments utilized during
bulk data transmission. The receive window size defaults in the
following manner:
TCPWindowSize = 8Kbytes rounded up to the nearest MSS increment for
the connection.
If that isn?t at least 4 times the MSS, then it?s adjusted to 4 *
MSS, with a maximum size of 64K
64K is the maximum window size due to the 16-bit size of the field in
the TCP header. RFC1323 describes a TCP window scale option that can be
used to obtain larger receive windows; however Windows NT TCP/IP does
not yet implement that option.
For Ethernet, the window will normally be set to 8760 bytes (8192
rounded up to six 1460-byte segments), and for 16/4 Token Ring or FDDI
it will be around 16Kbytes. These values are default and it?s not
generally advisable to alter them; however, there are two methods for
setting the receive window size to specific values:
The TcpWindowSize registry parameter (a global setting for the
system).
The setsockopt() Windows Sockets call (on a per-socket basis).
Throughput Considerations
TCP was designed to provide optimum performance over varying link
conditions. Actual throughput for a link is dependent on a number of
variables, but the most important factors are:
Link speed (bits/second that can be transmitted)
Propagation delay
Window size (amount of unacknowledged data that may be outstanding
on a TCP connection)
Link reliability
Router Congestion
TCP throughput calculation is discussed in detail in Chapters 20-24 of
TCP/IP Illustrated, by W. Richard Stevens. Some key considerations are
listed below:
The capacity of a pipe is (bandwidth * round-trip time). This is
known as the bandwidth-delay product. If the link is reliable, for
best performance the window size should be greater than or equal to
the capacity of the pipe. 65535 is the largest window size that can
be specified due to its 16-bit field in the TCP header. RFC1323
describes a Window Scale option; however it has not been
implemented yet by Windows NT TCP.
Throughput will never exceed (window size / round-trip time).
If the link is unreliable (or badly congested) and packets are
being dropped, using a larger window size may not improve
throughput.
Propagation delay is dependent upon the speed of light and
latencies in transmission equipment and so on.
Transmission delay depends on the speed of the media.
For a given path, propagation delay is fixed, but transmission
delay depends upon the packet size.
At low speeds, transmission delay is the limiting factor. At high
speeds, propagation delay may become the limiting factor.
To summarize, Windows NT TCP/IP will adapt to most network conditions
and dynamically provide the best throughput and reliability possible on
a per-connection basis. Attempts at manual tuning are often
counter-productive unless a careful study of data flow is performed by a
qualified network engineer.
------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------
So ...
So ...
The maximum window size supported by NT 3.51 or 4.0 is 65535 bytes and the
window size is the maximum amount of data that can be unacknowledged on a
TCP/IP connection. Since data is sent in packets, and for Tivoli Storage
Manager (or ADSM), we are always talking about sending data packets of the
full MTU size (OK, almost always), the sender can have sent at most N
unacknowledged packets, where N = 65535/MTU.
Now, of course the MTU depends on your network type and hardware, and can
be from 1500 bytes for Ethernet, 4352 bytes for FDDI, 17914 bytes for
TokenRing, and 9000 bytes for Gb Ethernet using jumbo frames. For
Ethernet,
we could have sent 43 packets if the window size is 65535, also 43 packets
if the window size is 64512 (63K), only 32 packets if the window size is
49152 (48K), and only 6 packets if the window size is 8760 bytes (default).
The TCP/IP guru implies that there is a fixed MTU size of 16K which has
some relationship to the 16 bit word within the IP stack, which is
absolutely untrue. Even if the MTU was 16KB, then for the maximum window
size, 63K, and 48K, we could have sent only 3 packets. It is absolutely
untrue that a packet would be sent if there is not room in the current
window size to send it (thus requiring it to be retransmitted later).
From the Throughput Considerations section above, it should be clear that
the window size should be maximized in order to provide optimal throughput.
However, there are some conditions that warrant a reduced window size, and
these include:
If the link is unreliable, a larger window size may cause more packets
to need to be retransmitted than would otherwise occur.
If the hardware does not have sufficient memory buffers, or the speed
to accept data at the incoming rate, there may be a point where a
large window size causes retransmits. I remember an early IBM
token-ring adapter that performed much worse with a large window size,
due to retransmits.
Do not exceed the limits of the software, particularly, the maximum
window size supported by NT 3.51 and NT 4.0 is 65535 (64K - 1 byte).
Since Win2000 provides RFC1323 support (window scaling), it can
support a much much larger window size, however, this only works with
connections to other systems that support window scaling (for example,
UNIX , and other Win2000 systems).
Since the Tivoli Storage Manager (ADSM) client option tcpwindowsize is
specified in KB, we blindly (for better or worse) multiply by 1024 and set
the option on the setsockopt() call. Specifying 64 is equivalent to trying
to set the window size to 64K, which is one byte too large, so NT uses the
default instead. It is very likely, but not guaranteed, that changing the
setting from tcpwindowsize 64 to tcpwindowsize 63 will improve throughput.
This applies to TSM (ADSM) clients and TSM (ADSM) servers running on NT
3.51 or NT 4.0.
Chris Zaremba
TDP Client (formerly ADSM Agent) Development
internet zaremba AT us.ibm DOT com
|
