Ethernet Card Recommendations
Network and Cabling Recommendations
Lean 'Network' Settings
Lean TCP/IP Settings for a Dynamically Assigned IP Address
Lean TCP/IP Settings for a Static IP Address
MTU, RWIN and TTL Values
Updating Windows
Optimizing Ethernet Based LAN Connections
by Mr. Echevarria - Originally Created November of 1999
Last Revised on 08/14/01 11:46:26 PM
TCP/IP optimization guidelines for Ethernet based connections, including Ethernet-based DSL, cable and ISDN connections. These guidelines optimize the OSI network layers within Windows itself to ensure that your system achieves maximum throughput rates when sending and receiving data. While the guidelines were constructed following Windows ME's property sheets, the advice applies to all version of Windows, including 95, 98, NT and 2000. Contact me with your suggestions, corrections or contributions.
Please choose a PCI based Ethernet adapter with the following basic qualities:
Please remember to install the card into a bus-master capable slot; consult your motherboard manual to determine which slot(s) meet that capability. Finally, buy an Ethernet card that can perform to your expectations, not merely based on price. For example, for a standard home computer a basic Ethernet card should suffice, but for a power user or server, opt for either a manageable or a specialty server card for maximum performance.
PPPoA versus PPPoE Adapter Note: If available, opt for a PPPoA connection instead of a PPPoE connection. PPPoA is more efficient than PPPoE, mainly because PPPoA doesn't add an additional layer of encapsulation (Ethernet); instead, your packets go directly over the ATM circuit after the PPP layer. Also, PPPoATM is an actual internet standard, whereas PPPoEthernet is still in the "informational" stage. Just remember, if you do use a PPPoA adapter instead of a PPPoE adapter, the rest of this document will be of little use, unless you are connected to a LAN as well as DSL.
Network Infrastructure & Cabling Recommendations
Poor network equipment and cabling can have a detrimental affect on your network's overall performance, following the recommendations listed below may help you make wise decisions for your future purchases.
Hubs versus Switches: If you primarily perform UDP-based transfers (for example, online-gaming), please be aware that a hub can cause up to 2% (4-port 100Mbit hub, average 25% usage) or more (depending on the size of the hub versus usage in the collision domain) of the packet loss you experience. Since most UDP-based applications don't retransmit lost or corrupt data, this internal packet loss can affect the enjoyment of said application, especially if external packet loss is also present in the data stream. Now that several DSL/Cable firewalling routers are available at differing price-points, it's important to choose one that will not interfere with the basic network operation of programs or applications that you normally use. For example, if you were a online-gamer looking into such a product, you would want to choose one with a built-in switch not a hub, since switches do not have collision domains and therefore would not cause internally-generated packet loss inside your internal network. If you primarily use TCP-based applications, you can opt for a lower priced hub over a switch; TCP connections are rarely bothered by the retransmission delays internal packet loss would cause. However, if your UDP traffic is strictly LAN based, the packet delay introduced by collisions on a hub is negligible since the random hold time for the Ethernet frame is measurable in nanoseconds and under normal hub use should not affect the enjoyment of the UDP application. This is in contrast to a UDP packet from outside the LAN where an external delay (measurable in milliseconds) is already affecting each packet.
Before you can complete this section you must have a basic knowledge of the type of TCP/IP network you are connected to and the capabilities of your Ethernet hardware.
Note: When using standard drivers provided with certain Ethernet adapters, the driver will default to half-duplex mode and not allow you to switch to full-duplex mode in the property sheets. To get around this limitation, obtain the driver for an "upscale" version of your Ethernet adapter, install it and then make the change to full-duplex as long as your network supports full duplex operation. Most hubs are half-duplex devices, not full-duplex, make sure you set your card accordingly; consult your hub's manual or contact the manufacturer if you are unsure.
Warning: It's important to know the limitations of the network equipment you connect to in order to maximize data transmission over said network. Certain switches and/or hubs require speed detection & negotiation or they may become confused, causing erratic network performance. If your network falls into this category, set your Ethernet adapter to auto-detect network speed and duplex mode instead of manually setting them.
Note: Depending on your network card, this setting may be a multiplier (16, 8, etc.) or a byte value (256, 128, etc.)--if in doubt, consult your manual. Also, this setting may increase CPU usage (Less than 1% on a Pentium for the 256 byte setting) according to how low you set it in relationship to how fast your computer is.
Warning: Do not set the transmit threshold below 60 bytes or you may experience an increase in network errors (collisions and runts), depending on the propagation delay for your network, among other things. (60 bytes is the minimum frame size for Ethernet, anything smaller is considered a "runt" and discarded.) Additionally, the number of bus-mastering devices in your system and the usage of such can have a direct effect on the number and frequency of underruns and other network errors when using a low transmit threshold. If you have a slow computer or experience network problems with the lower settings, set the transmit threshold to the safest method, "Store and Forward." Also, in a mixed speed network environment, don't try to force 100Mbits into 10Mbits--use the "Store and Forward" instead.
Attention: If you use this setting on multiple computers connected to a hub, you will probably see an increase in the number of collisions on the network, but an increase in collisions will usually not have much of an affect on overall network performance--collisions are a part of Ethernet. If necessary, you can always set the threshold low on certain computers and not on others until you reach a balance for your network. Switch users would not see an increase in network collisions, but if your switch allows you to set its transmit threshold, it will no longer check for corrupt Ethernet frames before forwarding them on. However, since corruption is rare on most small, well-put-together switched networks, the performance benefits may outweigh any such intermittent problems.
Warning: Setting this value higher than the cache line capacity of your CPU/PCI bus may lower ping values (3-20ms) on high-speed connections, but overall connection stability may be compromised when the PCI bus has multiple devices communicating with the CPU at the same time (PCI based Ethernet card, 3D video and/or 3D audio card) while performing intensive operations (online gaming, etc.). If you use an AGP-based video card you may be able to set this value to twice the cache line capacity (16 Dwords) without the connection performance hit, but at four times the cache line capacity (32 Dwords) the performance issue crops up as well.
Certain Ethernet adapters, especially high-end models, usually offer additional connection parameters. A basic rule of thumb is that most receive (RX) parameters can be set at higher values without causing connection problems since the receiving side is limited by the network itself and therefore would rarely exceed the upper range of its or the computer's capabilities. Of course, if you do begin to experience receive-related problems (see the warning below), resetting the adapter settings back to the defaults will resolve them. However, for most high-end model Ethernet adapters, unless you know the exact nature of the Ethernet frames on your network, the automatic TX and RX settings will probably provide the best overall performance. Be careful when increasing the RX Buffer setting beyond its default setting (normally between 16 and 48), as some adapters don't place an upper-limit on the setting; an RX Buffer setting of 200 should be considered the maximum (and more than adequate) for almost all Ethernet connections. Note: Depending on your network card buffer settings may be a multiplier or a number-of-packets value (32, 48, 64, etc. packets)--if in doubt, consult your manual. Also, some network cards have an internal driver limit on the receive buffer settings, meaning a setting of 128 is actually still a limit of 48, again, consult your manual if you are in doubt.
Warning: Do not increase the RX and other buffer settings beyond your computer's memory capacity. Doing so will seriously affect the performance of file sharing and other network-dependent services. An RX buffer setting of 48 should be the maximum for a 32Mb computer, 64 for a 64Mb computer, up to 200 for a 128Mb (at least) system. Memory for the RX and other buffers is reserved by the network card's driver directly from your computer's installed memory, in other words don't make the mistake of thinking that the network card itself has built-in memory--only certain high-end network cards offer that luxury. Increasing the buffer size beyond your memory capacity will force a heavier reliance on virtual memory, which (depending on the speed of your hard drive and its controller) may begin to cause a cumulative overall performance degradation when your system is under heavy memory load. Note: If you have more than one Ethernet adapter in your computer the maximum recommended buffer size should be reduced accordingly with respect to installed memory. For example, on a 64Mb computer with two network cards the buffer size should not be set higher than 48, perhaps even as low as 32 depending on the memory usage of other active programs.
Lean TCP/IP Settings for a Dynamically Assigned IP Address
If you do not use other network protocols/adapters/services, remove everything except the components required for TCP/IP Ethernet connections: Your Ethernet adapter and TCP/IP. If you are optimizing a Internet connection that requires you to logon (certain DSL and cable services), the Dial-Up Adapter component is also required.
Lean TCP/IP Settings for a Static IP Address
If you do not use other network protocols/adapters/services, remove everything except the components required for TCP/IP Ethernet connections: Your Ethernet adapter and TCP/IP. If you are optimizing a Internet connection that requires you to logon (certain DSL and cable services), the Dial-Up Adapter component is also required.
Neither the MTU nor TTL for most Ethernet (including PPPoA) style connections need to be adjusted from the standard values. Windows ME only requires RWIN adjustment for Ethernet type connections. However, PPPoE users are different, they should set the MTU be within the guidelines specified in RFC 2516 and then base the RWIN off of the lower RFC 2516 MTU of 1492. If the ISP-supplied PPPoE implementation does not follow RFC 2516, the MTU should be set to the ISP implementation PPPoE size and of course, the RWIN should then be set as a multiple of the non-RFC 2516 MTU size.
Please note: Unless you use PPPoE under Windows NT or 2000, this section only applies to Windows 9x and ME. Windows NT and 2000 have self-tuning TCP/IP stacks and do not require RWIN adjustment for Ethernet or PPPoA connections, please skip this section.
(Note: If you do not understand basic algebra, you might want to skip this entire section.)
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\DefaultRcvWindow]
RWIN directly affects throughput, do not set it below the default of 8192 or Windows will be unable to properly buffer TCP packets. Conversely, do not set it too high (above 65535) or Windows may be unable to properly request retransmissions to correct TCP packet errors, resulting in uncorrected errors during large data transfers.
Important: Despite what others may claim, under normal conditions there are no benefits to setting an RWIN higher than 65535. The performance limit of a TCP connection can be calculated by dividing the RWIN (receive window) by the delay (ping time) to the destination. For example, using Windows 9x's default window size of 8192, a 120ms delay would limit throughput to about 68k per second, while a larger delay of 300ms would limit throughput to a maximum of about 27k per second. Increasing the receive window to the max of 64240 under a 120ms delay increases the TCP's theoretical performance limit to 535k per second--well beyond the theoretical maximum of 193k per second for a 1.544Mbit connection. Basically, you can't squeeze 535k per second of TCP out of a physical connection method that only does a maximum (not including compression) of 193k per second! Don't allow yourself to be fooled. Additionally, the receive window scaling functions that are automatically active in Windows 98, ME and 2000 function more efficiently with a realistic RWIN.
Increase connection performance and overall system stability by installing the latest system updates for your particular version of Windows, click here for the updates page.
Disclaimer: I am not responsible for any problems you may encounter when following these recommendations. I use all of the above recommendations with outstanding success. This page assumes your system is completely free of existing issues and that none of the above settings have been previously altered. Finally, networks are unique, so while I can recommend certain universal settings for performance improvement, ultimately it is you who must realize what recommendations will work with your network and which ones will not...when in doubt, contact your system administrator, technical support and/or help desk.
© Copyright 1999 & 2000 - Mr. Echevarria
Please respect my copyright.