Sg tcp optimizer windows 10


LAN Tweaks for Windows 7, 8, 10

Fix issues and improve local area network and file sharing performance 2014-04-08 (updated: 2017-01-13) by Philip

The information in this article focuses on improving local area network performance and file sharing under Windows 7, 8, 10, as well as 2008/2012 Server. The tweaks below can be used in addition to our general broadband tweaks. Some proficiency in editing the Windows Registry is expected.

Network Memory Allocation (Event ID 2017 error)

This tweak applies to Windows 7, 8, 10, 2008 server, and 2012 Server. It can be applied using the SG TCP Optimizer as well.

When using Windows to serve many/large files over the local network, it is possible to sometimes run into memory allocation errors related to the Windows share, especially with clients that use different operating systems. When this happens, you can usually see the following error in the Event Viewer System log:

Event ID: 2017  "The server was unable to allocate from the system nonpaged pool because the server reached the configured limit for nonpaged pool allocations." It is also possible to get an error indicating that "Not enough server storage is available to process this command". To avoid those errors, you need to change the way Windows allocates memory for network services and file sharing. The below settings optimize the machine as a file server so it would allocate resources accordingly. There are two related registry settings:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory ManagementLargeSystemCache=1 (DWORD, default value: 0, recommended value: 1 for LAN transfers, 0 for gaming)A value of zero establishes a cache of ~8 MB, a value of 1 allows the cache to expand up to the amount of physical memory minus 4 MB, as necessary. It improves large file transfers over Gigabit LANS, reportedly some ATI videocards' drivers have an issue with it so we recommend to leave it off/zero for gaming.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\ParametersSize=3 (DWORD, default value: 1, recommended value: 3)1 - minimizes used memory2 - balance used memory3 - optimal setting for file sharing and network applications

Network Throttling Index

Applies to Windows 7, 8, 10, 2008 Server, and 2012 Server. Setting can be applied using the TCP Optimizer as well.

By default, Windows implements a network throttling mechanism to restrict the processing of non-multimedia network traffic to 10 packets per millisecond (a bit over 100 Mbits/second). The idea behind such throttling is that processing of network packets can be a resource-intensive task, and it may need to be throttled to give prioritized CPU access to multimedia programs. In some cases, such as Gigabit networks and some online games, for example, it is beneficial to turn off such throttling all together for achieving maximum throughput.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfileNetworkThrottlingIndex=ffffffff  (DWORD, default: 10, recommended: 10 for media sharing, ffffffff for gaming and max throughput, valid range: 1 through 70 decimal or ffffffff to completely disable throttling)

It is only recommended to change this setting in saturated Gigabit LAN environments, where you do not want to give priority to multimedia playback. Reportedly, disabling throttling can also help reduce ping spikes in some online games.

Other Common Issues and Fixes

Lost Connection to Mapped Drive

Mapped drive is disconnected after inactivity, Windows Explorer shows a red "X" on the icon of the mapped drive, but you can browse the mapped drive and it reconnects.Change the default time-out period on the shared network computer.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parametersautodisconnect = ffffffff (DWORD, default: 15, recommended: ffffffff)HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Service\lanmanworkstation\parametersKeepConn = 32000 (DWORD, default: not present)

Note: Setting applies to Windows 7, 8, 10, 2008 Server, 2012 Server

Not Enough Server Storage

is Available to Process this Command error

The server's IRPStackSize is too small for the server to use a local device. You may experience the following error messages:

Not enough server storage is available to process this commandNot enough memory to complete transaction. Close some applications and retry

Increase IRPStackSize to fix this:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\ParametersIRPStackSize = 30 (DWORD, default: 15, recommended: 30, maximum value: 50)

Note: Setting can ve applied to Windows 7, 8, 10, 2008 Server, 2012 Server

Disable SMB2 on Windows 7 File Server with Windows XP Clients

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\ParametersSMB2 = 0 (DWORD, default: not present assumes 1, recommended: 0 if using clients with older Windows variants)SMB1 = 1 (DWORD, default: not present assumes 1-enabled, recommended: 1 - no need to add or change)

Under Windows 8/10/2012 Server, you can also disable SMB2/3 using PowerShell cmdlets:

Set-SmbServerConfiguration -EnableSMB2Protocol $false

References: MS KB2696547

See Also

Wireless Network Speed Tweaks

Network Adapter Optimization

www.speedguide.net

Windows 8, 10, 2012 Server TCP/IP Tweaks

Tweak TCP/IP in Windows 8,10,2012 to speed up your broadband internet 2014-12-12 (updated: 2017-01-13) by PhilipTags: CTCP, Windows 8, TCP/IP, PowerShell, tweaks, Chimney Offload, TCP Window, ICW, netsh, DCA, Windows 10, RWIN

The Windows 8 TCP/IP implementation shares many traits with earlier Windows versions, however, there are some subtle differences, new syntax for applying tweaks, and some new settings. Windows 8 generally works well by default for many broadband connections, yet there is always some room for improvement and we will try to cover all relevant settings and their effect on your connection in detail below.

To run some of the outlined commands, you will need to use an administrator account. With earlier Windows versions, we used the netsh command in elevated command prompt to tweak most of the TCP/IP settings. With the introduction of Windows 8/Server 2012, some of those parameters are only tweakable by using the Windows PowerShell, that is why we will be using it for settings when possible. Note that netsh and other DOS commands are still available under PowerShell , just as with Command Prompt.

The settings outlined bellow work with Windows 8, 8.1, Windows 10 Technical Preview, Windows Server 2012, and 2012 R2 (with only minor syntax differences). If you'd rather use our free software to apply all those settings, try the SG TCP Optimizer (v.4).

Windows PowerShell

The Windows PowerShell is a tool developed by Microsoft designed to replace and extend the functionality of the command prompt. It allows you to run all DOS commands similarly to command prompt, however, it also provides additional functionality in the form of many customizable commands called cmdlets.  We will be using PowerShell to tweak TCP/IP settings, as some of the parameters are no longer tweakable using command prompt netsh in Windows 8 and newer OSes.

In Windows 8, the easiest way to find PowerShell is by searching for PowerShell on your Start screen/menu. It can also be accessed from the Windows System folder. You should right-click on PowerShell and choose "Run as administrator" so that you have sufficient permissions to tweak all applicable settings.

The PowerShell commands below are an overview of what we can use to tweak TCP/IP settings under Windows 8:

Get-NetTCPSetting  -  this can be used to view TCP parametersSet-NetTCPSetting  -  this can be used to set TCP parameters

netsh int tcp show global - you can still see and change some (not all) parameters using netsh

 

There are a few different networking profiles called "templates" in Windows 8 PowerShell under Get-NetTCPSetting.In Windows 8 (and 2012 Server): Automatic, Internet, Datacenter, CompatIn Windows 8.1 (also Windows 10, Windows 2012 Server R2): Automatic, Internet, InternetCustom, Datacenter, DataCenterCustom, Compat

Theoretically, only one of the above templates can be modified by default - "Custom" under Windows 8, "InternetCustom" under Windows 8.1 (and Windows 10).  The "DatacenterCustom" template can only be modified if Windows is installed on a server. If you try to modify one of the other templates, you will get an error, something like:

Set-NetTCPSetting : Only the custom templates InternetCustom and DatacenterCustom can be modified.

Even though theoretically only the "Custom" templates can be modified, many of the commands below (both netsh and PowerShell TCP cmdlets) are global and modify all templates simultaneously.

By default, the "Internet" template/profile is applied to TCP connections. To find the currently used template using PowerShell cmdlets type either:

Get-NetTCPConnection , or Get-NetTransportFilter(using netsh, you can type: netsh int tcp show supplemental)

Notes:PowerShell cmdlets are case-insensitive, so typing get-nettcpsetting is the same as  Get-NetTCPSetting.

Even though some settings below modify all "templates", it may still be necessary to sometimes change the default template used for TCP connections from Internet to Custom/InternetCustom. The following command supposedly changes the default (does not work as documented by MS under Windows 8/8.1):set-NetTCPConnection -AutomaticUseCustom true(acceptable parameters are [true|false], doesn't seem to work in Windows 8.1 ?)

Useful TCP/IP connection related cmdlets:Get-Help Get-NetTCPSetting -detailed  (help on NetTCPSetting)Get-NetTCPConnection   (see active connections)(Get-NetTransportFilter | Where DestinationPrefix -eq '*' | Get-NetTCPSetting)  -- view current template settings(Get-NetTransportFilter | Where DestinationPrefix -eq '*' | Get-NetTCPSetting).CongestionProvider  -- view only "CongestionProvider" setting in currently used template

See also: MS TechNet Set-NetTCPSetting

Netsh

It is still possible to check the current status of Windows TCP/IP parameters with netsh, both in PowerShell and elevated command prompt. We recommend using the PowerShell for all changes. While most settings can still be changed using the "netsh" tool, others require the Windows PowerShell interface and cmdlets. Netsh (and the command prompt) is being deprecated by Microsoft, and some of the netsh commands are bugged in Windows 8/8.1 and Server 2012/2012 R2.

To see current tcp parameters in netsh, use:

netsh int tcp show global

You will see something like the following:

There are two extra settings in Windows 8.1 and Windows 10 (right image above)

Explanation of all the tweakable TCP/IP parameters, possible ways to change them, as well as their default/recommended states for broadband internet connections are listed below. We recommend using the Windows PowerShell for all changes. The parameters are loosely sorted in order of importance with the parameters that generally have more significant impact listed first.

Receive Window Auto-Tuning Level

The TCP Receive Window has a very important role in TCP connections. It can limit throughput, especially in high-speed, high-latency environments, such as most internet connections. For more information on how it limits your speed, check our TCP Window article.

The possible settings are as follows:

disabled: uses a fixed value for the tcp receive window. Limits it to 64KB (limited at 65535).highlyrestricted: allows the receive window to grow beyond its default value, very conservativelyrestricted: somewhat restricted growth of the tcp receive window beyond its default valuenormal: default value, allows the receive window to grow to accommodate most conditionsexperimental: allows the receive window to grow to accommodate extreme scenarios (not recommended, it can degrade performance in common scenarios, only intended for research purposes. It enables RWIN values of over 16 MB)

Default setting: normalOur recommendation: normal  (unless you're experiencing problems)

To modify, in PowerShell (or elevated command prompt) type:

netsh int tcp set global autotuninglevel=normal(where "normal" is one of the above listed possible states)

Same can also be accomplished using PowerShell cmdlets, just type:

Set-NetTCPSetting -SettingName InternetCustom -AutoTuningLevelLocal Normal

Note: You can also try "highlyrestricted" autotuninglevel for up to 10Mbps connections, as it actually uses a higher unscaled RWIN value (16384 vs. 256 bytes), and still scales up to 262140 bytes.

Disable Windows Scaling heuristics

Windows 8 (as with Windows 7) has the ability to automatically change its own TCP Window auto-tuning behavior to a more conservative state regardless of any user settings. When heuristics restricts your autotuning level, you may see this message when viewing netsh settings:

"** The above autotuninglevel setting is the result of Windows Scaling heuristics overriding any local/policy configuration on at least one profile."

When heuristics restricts autotuning level, the "netsh int tcp show global" command will still (incorrectly) show your user-set autotuning level, you have to use "netsh int tcp show heuristics" to see the actual current heuristics restriction. To enforce the user-set TCP Receive Window autotuning level and prevent heuristics from restricting how the TCP Receive Window grows, disable heuristics. It is best to disable this before applying autotuning level to ensure your user-set autotuning level is retained.

default state: OS-dependent (disabled in Windows 8.1, enabled in Windows 7)possible settings are: disabled,enabled,default (sets to the Windows default state)recommended: disabled (to retain user-set RWIN auto-tuning level)

To disable explicitly using netsh:

netsh int tcp set heuristics disabled

To see the current heuristics state:

netsh int tcp show heuristics

Using PowerShell cmdlets:

Set-NetTCPSetting -SettingName InternetCustom -ScalingHeuristics Disabled

Notes:If heuristics are not explicitly disabled, Windows can restrict the RWIN autotuninglevel at any time. When that happens, viewing your settings with "netsh int tcp show global" will still incorrectly show user-set autotuninglevel, only "netsh int tcp show heuristics" reveals the restriction.

The registry value that was used in Windows 7 and earlier is no longer present in the Windows Registry (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\EnableWsd=0 (not present for Windows 8))

Add-On Congestion Control Provider (CTCP)

The traditional slow-start and congestion avoidance algorithms in TCP help avoid network congestion by gradually increasing the TCP window at the beginning of transfers until the TCP Receive Window boundary is reached, or packet loss occurs. For broadband internet connections that combine high TCP Window with higher latency (high BDP), these algorithms do not increase the TCP windows fast enough to fully utilize the bandwidth of the connection.

Compound TCP (CTCP) is a newer congestion control method that increases the TCP Send Window more aggressively for broadband connections (with large RWIN and BDP). CTCP attempts to maximize throughput by monitoring delay variations and packet loss. It also ensures that its behavior does not impact other TCP connections negatively. CTCP is turned on in Windows 8, and Server editions by default, but off in Windows 7. Keeping CTCP on can significantly increase throughput and packet loss recovery.

Possible settings are: none, ctcp, dctcp (Datacenter TCP)Default : CTCP **  (netsh incorrectly shows "none" by default, while PowerShell Get-NetTCPSetting shows "CTCP". netsh is deprecated and incorrect)Recommended: CTCP

CTCP - Compound TCP increases the receive window and amount of data sent. It can improve throughput on higher latency/broadband internet connections.DCTCP - Data Center TCP adjusts the TCP Window based on network congestion feedback based on Explicit Congestion Notification (ECN) signaling, it is designed to improve throughput on low latency/local links.

Unfortunately, netsh is bugged for this setting, and the PowerShell cmdlet only works for server Windows variants, so there is no longer an easy one line command that can change the congestion provider. Yay for Microsoft! Fortunately, the default setting is already CTCP, as per the PowerShell Get-NetTCPSetting cmdlet.

To change using PowerShell cmdlet:

Set-NetTCPSetting -SettingName InternetCustom -CongestionProvider CTCP

("InternetCustom" template is for Windows 8.1, change to "Custom" for Windows 8)

To see the current Congestion provider, use:  Get-NetTcpSettingAlternatively, you can go wild and use the cmdlet below to see only the congestion provider of the currently used template: (Get-NetTransportFilter | Where DestinationPrefix -eq '*' | Get-NetTCPSetting).CongestionProvider

Notes:Changing CTCP directly with netsh is not possible by default under Windows 8, those commands are listed just for reference:

netsh int tcp show supplemental  (see the currently used supplemental template)netsh int tcp set supplemental custom 300 10 ctcp disabled 50  (minrto=300ms, initial congestion window icw=10 packets, congestionprovider=ctcp, enablecwndrestart=disabled,   delayedacktimeout=100 ms) netsh int tcp set supplemental custom (tell Windows to use the custom template)

You can still "hack" Windows 8 to show CTCP in netsh by doing the following:

1. Open notepad and copy this code into it:

How to set the congestion provider to ctcpWindows Registry Editor Version 5.00[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nsi\{eb004a03-9b1a-11d4-9123-0050047759bc}\0]"0200"=hex:00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\00,00,00,00,00,00,02,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\00,00,00,ff,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\ff,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00"1700"=hex:00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\00,00,00,00,00,00,02,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\00,00,00,ff,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\ff,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00

2. Save file with .reg extension, for example: "enable-ctcp.reg"3. Import the registry file into the Windows Registry (double-clicking on it should do it, after a warning).4. RebootAlternatively, get [this file] (right-click, "save target as", save with .reg extension so that it can be merged with the registry automatically when double-clicked).

Here is a screenshot from Windows 8.1 after merging the above with the registry and rebooting:

You can also just copy all the text to the appropriate registry hive directly. Merging the above with the registry and rebooting will show CTCP as the addon congestion control algorithm. Still, as per Microsoft, netsh is deprecated and you should be using Powershell.

Note that the above registry hack will change not only CTCP, but other related parameters as well, here is some additional info:

The binary values above affect many parameters: "Chimney Offload State" (offset 04, 00=disabled,01=enabled,02=auto), RSS (offset 05, 00=default/enabled,01=disabled), ECN Capability (offset 06, 00=disabled/default, 01=enabled), CTCP (offset 28, 00=none, 02 = ctcp), etc.

TCP Chimney Offload

TCP chimney offload enables Windows to offload all TCP processing for a connection to a network adapter (with proper driver support). Offloads are initiated on a per-connection basis and reduce networking-related CPU overhead, theoretically enabling better overall system performance by freeing up CPU time for other tasks. TCP Chimney Offload controls what is referred to as the "TCP Offload Engine" (TOE) in Windows in general. It is a global setting that has to be enabled for many of the other offloads to work. Enabling this setting had some negative effects in the past because of buggy network adapter drivers, however its implementation has gotten much better with time. It is useful for CPU-bound client computers and very fast broadband connections, not recommended in some server environments.

All the possible states of this setting are as follows:

automatic - offloads if the connection is 10 GbE, has a RTT default - this setting restores chimney offload to the system default.disabled - chimney offload disabled.enabled - chimney offload enabled.

Default: automaticRecommended: disabled

To disable TCP Chimney Offload:

netsh int tcp set global chimney=disabled

Using Powershell, to set the offload state:

Set-NetOffloadGlobalSetting -Chimney Disabled   (default: disabled, possible states: enabled/disabled/automatic, recommended: disabled*)

To view the current chimney state:

(Get-NetOffloadGlobalSetting).Chimney

or, simply:

Get-NetOffloadGlobalSetting

Notes:* There were issues with buggy Network adapter drivers and the implementation of offloading with older OSes (Windows 2003 Server), however, this has improved over time. One should be more careful using offloading in server environments, as there have been some reports of issues with TCP Chimney Offload and SQL servers under heavy load, affecting both application concurrency and throughput. See this MSDN reference and MS KB942861.

Chimney Offload does not work together with NetDMA (mute point with Windows 8/8.1 as NetDMA is not supported).

Chimney Offload may not be supported with NAT/ICS (reference: Technet TCP Chimney Offload Compatibility for Windows 2008 R2). However, this only applies if NAT/ICS is enabled on the computer running Windows itself, and that is rarely the case.

Setting Chimney Offload to disabled is recommended for VMWare servers, and the setting is now considered deprecated by Microsoft. See: Obsolete RFCs and Overview of TCP Timers

NetDMA State

NetDMA (TCPA) enables support for advanced direct memory access. In essence, it provides the ability to more efficiently move network data by minimizing CPU usage. NetDMA frees the CPU from handling memory data transfers between network card data buffers and application buffers by using a DMA engine.

Default: disabledRecommended: leave alone, don't bother (setting not supported in Windows 8 and later, according to MS)

You can still edit it using:

netsh int tcp set global netdma=disabled

Notes:According to Microsoft, NetDMA is not supported in Windows 8/8.1 and changing this setting will have no effect. See: MSDN NetDMA

NetDMA (TCPA) does not work together with Chimney Offload either, you have to choose one or the other. For NetDMA to work, it must be enabled/supported by your BIOS and your CPU must support Intel I/O Acceleration Technology (I/OAT).

Direct Cache Access (DCA)

Direct Cache Access (DCA) allows a capable I/O device, such as a network controller, to deliver data directly into a CPU cache. The objective of DCA is to reduce memory latency and the memory bandwidth requirement in high bandwidth (Gigabit) environments. DCA requires support from the I/O device, system chipset, and CPU(s).

Possible states are: enabled, disabledDefault state: disabledRecommended: enabled (provided the CPU/Chipset/NIC support it)

To set DCA using netsh:

netsh int tcp set global dca=enabled

Note: The impact of DCA is more significant with older CPUs.

The PowerShell Enable-NEtAdapterChecksumOffload cmdlet enables checksum offloads on the network adapter. Checksum offloading is also required for some other stateless offloads to work, including Receive Side Scaling (RSS), Receive Segment Coalescing (RSC), and Large Send Offload (LSO).

Default state: adapter-dependentRecommended: enabled

In PowerShell:

Enable-NetAdapterChecksumOffload -Name * (use to enable checksum offload on all adapters that support it)Disable-NetAdapterChecksumOffload -Name *    (use to disable checksum offload for all network adapters)Get-NetAdapterChecksumOffload       (use to view network adapters that support checksum offload and their state)

The above PowerShell cmdlet example enables checksum offloads on all visible network adapters for all UDP/TCP/IP version 4 and version 6 traffic (and restarts the network adapters). Alternatively, you can specify only a single network adapter and/or protocol by using command-line switches. For more information on customizing the command, refer to this Technet article.  To pick a single adapter and only modify its checksum offload state, find installed adapters using this cmdlet: Get-NetAdapter

Receive-Side Scaling State (RSS)

The receive-side scaling setting enables parallelized processing of received packets on multiple processors, while avoiding packet reordering. It avoids packet reordering by separating packets into "flows", and using a single processor for processing all the packets for a given flow. Packets are separated into flows by computing a hash value based on specific fields in each packet, and the resulting hash values are used to select a processor for processing the flow. This approach ensures that all packets belonging to a given TCP connection will be queued to the same processor, in the same order that they were received by the network adapter.

Default: enabledRecommended: enabled (provided you have 2 or more processor cores and a NIC that can handle RSS)

To change RSS using netsh:

netsh int tcp set global rss=enabled

To change using PowerShell cmdlets:

Enable-NetAdapterRss -Name *    (use this to enable RSS for all adapters that support it)Disable-NetAdapterRss -Name *     (use this to disables RSS for all adapters)Get-NetAdapterRss -Name *          (use cmdlet to view RSS capable Network Adapters)

Notes:Needs Checksum Offload to be enabled. Only supported by some network adapters.

Receive Segment Coalescing State (RSC)

Receive Segment Coalescing (RSC) allows the NIC to coalesce multiple TCP/IP packets that arrive within a single interrupt into a single larger packet (up to 64KB) so that the network stack has to process fewer headers, resulting in a 10% to 30% reduction in I/O overhead depending on the workload, thereby improving performance. Receive Segment Coalescing (RCS) is able to collect packets that are received during the same interrupt cycle and put them together so that they can be more efficiently delivered to the network stack. This can significantly increase the amount of traffic that can be handled without severely impacting the CPU.

Possible states: enabled, disabled, defaultDefault state: disabledRecommended: enabled for better throughput, disabled for pure gaming to ensure lowest latency.

To enable using netsh:

netsh int tcp set global rsc=enabled

To enable using PowerShell cmdlets:

Enable-NetAdapterRsc -Name *  (use to enables RSC for all adapters that support it)Disable-NetAdapterRsc -Name *       (use to disable RSC for all adapters)Get-NetAdapterRsc -Name *            (use to view adapters that support RSC)

Notes: Needs Checksum Offload to be enabled. Only supported by some network adapters.For gaming, where latency is more important than pure throughput, any type of packet/memory coalescing should be disabled or used very sparingly. Packet/memory coalescing reduces CPU utilization and increases throughput, however, it causes the network adapter to combine packets before interacting with other hardware, which may slightly increase latency. Also see our gaming tweaks article.

Large Send Offload (LSO)

This setting enables Large Send Offload. When enabled, the network adapter hardware is used to complete data segmentation, theoretically faster than operating system software. Theoretically, this feature may improve transmission performance, and reduce CPU load. LSO reduces the interrupt rate and the amount of bus transactions to the NIC. The problem with this setting is buggy implementation on many levels, including Network Adapter Drivers. Intel and Broadcom drivers are known to have this enabled by default, and may have many issues with it. It should only be enabled with the newest Gigabit NICs with recent drivers. Because of the issues mentioned above, we recommend disabling LSO at both the Network Adapter properties, and at the OS level with the setting below.

Default: adapter-dependentRecommended: disable (both in network adapter properties and in the TCP/IP stack at the OS level)

Disable-NetAdapterLso -Name *    (disable LSO for all visible network adapters)Enable-NetAdapterLso -Name *    (enable LSO for both IPv4 and IPv6 on all network adapters. Be careful with this setting, test before using in production)Get-NetAdapterLso -Name *  (get a list of network adapters that support LSO)

Notes: Default state is network adapter dependent. Needs Checksum Offload to be enabled to work. LSO is another buffer that may impact latency, it is not recommended for interactive connections and gaming.See Also:  Should I enable TCP Offloading ?

ECN Capability

ECN (Explicit Congestion Notification, RFC 3168) is a mechanism that provides routers with an alternate method of communicating network congestion. It is aimed to decrease retransmissions. In essence, ECN assumes that the cause of any packet loss is router congestion. It allows routers experiencing congestion to mark packets and allow clients to automatically lower their transfer rate to prevent further packet loss. Traditionally, TCP/IP networks signal congestion by dropping packets. When ECN is successfully negotiated, an ECN-aware router may set a bit in the IP header (in the DiffServ field) instead of dropping a packet in order to signal congestion. The receiver echoes the congestion indication to the sender, which must react as though a packet drop were detected. ECN is disabled by default in modern Windows TCP/IP implementations, as it is possible that it may cause problems with some outdated routers that drop packets with the ECN bit set, rather than ignoring the bit.

Possible settings are: enabled, disabled, default (restores the state to the system default).Default state: disabled

Recommendation: "enabled" only for short-lived, interactive connections and HTTP requests with routers that support it, in the presence of congestion/packet loss, "disabled" otherwise (for pure bulk throughput with large TCP Window, no regular congestion/packet loss, or outdated routers without ECN support).

To change using netsh:

netsh int tcp set global ecncapability=default

To change using PowerShell cmdlets:

Set-NetTCPSetting -SettingName InternetCustom -EcnCapability Disabled

Notes:Alternative netsh syntax is: netsh int tcp set global ecn=default

ECN is only effective in combination with AQM (Active Queue Management) router policy. It has more noticeable effect on performance with interactive connections, online games, and HTTP requests, in the presence of router congestion/packet loss. Its effect on bulk throughput with large TCP Window are less clear. Currently, we do not recommend enabling this setting, as reportedly it has negative impact on throughput with some residential US ISPs. EA multiplayer games that require a profile logon do not support ECN as well (you will not be able to logon). However, it can also reduce latency in some games with ECN-capable routers in the presence of packet loss (dropped packets).

See also: Wikipedia - ECN, RFC 3168

RFC 1323 ads many useful options, most notably scaling of the TCP Window.  "Timestamps" (TSOpt) is a less commonly used 1323 option that is intended to increase transmission reliability by retransmitting segments that are not acknowledged within some retransmission timeout (RTO) interval. The problem with timestamps is that they add 12 bytes to the 20-byte TCP header of each packet, so turning them on causes considerable overhead.

Possible states: enabled,disabled,defaultDefault state: disabledRecommended: disabled

To set using netsh:

netsh int tcp set global timestamps=disabled

To set using PowerShell cmdlets:

Set-NetTCPSetting -SettingName InternetCustom -Timestamps Disabled

Initial RTO and Min RTO

Retransmit timeout (RTO) determines how many milliseconds of unacknowledged data it takes before the connection is aborted. The default timeout for Initial RTO of 3 seconds can usually be lowered for low-latency modern broadband connections, unless you're in a remote location, on a satellite internet connection, or experiencing high latency. In high-latency situations, this can increase retransmissions if the RTO value is reached on a regular basis.

InitialRTODefault value: 3000 (3 seconds)Recommended: between 2000 (2 seconds) and 3000 (3 seconds).

To set using netsh:

netsh int tcp set global initialRto=3000

To set using PowerShell cmdlets:

Set-NetTCPSetting -SettingName InternetCustom -InitialRto 3000

MinRTODefault value: 300 (ms)Recommended: 300 (ms)

MinRTO can't be changed under Windows 8 (read-only error), it may be editable under server OSes. The command is:

set-NetTCPSetting -SettingName InternetCustom -MinRto 300

Non Sack Rtt Resiliency (Windows 8.1)

Enables/Disables RTT resiliency for non SACK clients.  This can help slow clients/connections as it makes TCP/IP less aggressive in retransmitting.

Possible states: enabled,disabled,defaultDefault state: disabledRecommended: disabled

To set using netsh:

netsh int tcp set global nonsackrttresiliency=disabled

To set using PowerShell cmdlets:

Set-NetTCPSetting -SettingName InternetCustom -NonSackRttResiliency disabled

Note: This property only supported in Windows 8.1 and Windows Server 2012 R2.

Max SYN Retransmissions (Windows 8.1)

Sets the number of times to attempt to reestablish a connection with SYN packets.

Possible values: 2 to 8Default value: 2Recommended: leave at 2

To set using netsh:

netsh int tsp set global maxsynretransmissions=2

To set using PowerShell cmdlets:

Set-NetTCPSetting -SettingName InternetCustom -MaxSynRetransmissions 2

To view the current setting under PowerShell:

Get-NetTCPSetting -SettingName InternetCustomOr, to view only the current MaxSynRetransmissions setting as a number:(Get-NetTCPSetting -SettingName InternetCustom).MaxSynRetransmissions

Note: This property only supported in Windows 8.1 and Windows Server 2012 R2. Windows 7 hotfix displays it in netsh as a read-only setting.

InitialCongestionWindow (ICW)

When creating a TCP connection, the sending side performs a "TCP slow start" regardles of the receiver RWIN value. TCP slow start only sends two frames, waits for ACK response, and increases speed exponentially provided there are no dropped packets. This slow start algorithm can also be activated if there is no traffic for 200ms. This is not optimal for fast internet connections with intermittent bursts of data. This bottleneck can be avoided by increasing the "InitialcongestionWindow" from the default 2 (or 4) frames to 10 (See RFC 3390 and RFC 6928).

The following should work for 2012 server, however it does not work in Windows 8.1 (read-only setting error):

Set-NetTCPSetting -SettingName InternetCustom -InitialCongestionWindow 10

The following command works for Server 2008 R2 (with hotfix KB2472264 linked below):

netsh int tcp set supplemental template=custom icw=10

Setting MTU

It is sometimes useful to view and set the Maximum Transmission Unit (MTU) value for a specific network adapter manually. To view a list of active network interfaces, their names and their respective MTU values in Windows 8, open PowerShell (or command prompt) as administrator and run the following command:

netsh int ipv4 show subinterface

or, if you are using IP version 6:netsh int ipv6 show subinterface

Alternative netsh syntax:  netsh int ipv4 show interfacesAlternative PowerShell syntax: Get-NetAdapter  (to view all advanced properties: Get-NetAdapterAdvancedProperty)

You will be presented with a list of interfaces, and their respective MTU values as follows:

To change the MTU value of a specific network card, type the following:

netsh int ipv4 set subinterface "network interface name" mtu=#### store=persistent

Where "network interface name" is your specific network adapter name as obtained above (also viewable under Network adapters), and mtu=#### is the desired MTU value. For example, if the name of your network card is "Wi-Fi" and you'd like to set its MTU to 1500, you'd have to type:

netsh int ipv4 set subinterface "Wi-Fi" mtu=1500 store=persistent

Notes:For IPv6, you can set the MTU using:  netsh int ipv6 set subinterface "Wi-Fi" mtu=1500 store=persistentThe maximum MTU value is usually 1500, and up to 1492 for PPPoE connections.The PowerShell cmdlet using Set-NetAdapterAdvancedProperty SetMTU doesn't seem to work yet. See this nice attempt to set MTU using PowerShell at Serverfault.

Registry Tweaks

This section lists a number of TCP/IP related Windows Registry parameters that work with Windows 8/8.1 and 2012 Server. Some of the settings we've tested are the same/similar parameters as with previous Windows versions that we have confirmed to work with Windows 8/8.1 as well, although they may have different default values. Below is a list of what we've confirmed to work. To edit the Windows Registry, click the Windows button, and type: regedit in the search dialog (you may have to right-click regedit and choose to run as administrator to have the proper write permissions). It is always a good idea to create a restore point and backup the registry before making changes.

DefaultTTL

TTL does not directly affect speed, and can be safely left alone in many cases. It is a limit to the time and number of hops/routers a packet will travel before being discarded. A number that's too small risks packets being discarded before reaching their destination. A number that's too large (over 128) will cause delay in when lost IP packets are discarded. The default, when the setting is not present in the Windows 8/10/2012 registry the system assumes a value of 128.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\ParametersDefaultTTL=64  (DWORD, not present by default denoting 128, valid range is 1-255, recommended: 64)

Host Resolution Priority Tweak

This is intended to increase the priority of DNS/hostname resolution, by increasing the priority of four related processes from their defaults. It is important to note that this increases their priority compared to the hundreds of other running processes, while keeping their order. See our Host Resolution Priority Tweak article for more details. The registry location under Windows 8, 8.1, 10, 2012 Server, and 2012 R2 is:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\ServiceProvider\LocalPriority = 4 (DWORD, default 499, recommended 4)HostPriority = 5 (DWORD, default 500, recommended 5)DnsPriority = 6 (DWORD, default 2000, recommended 6)NetbtPriority = 7 (DWORD, default 2001, recommended 7)

MaxUserPort and TCPTimedWaitDelay (port allocation)

Short lived (ephemeral) TCP/IP ports above 1024 are allocated as needed by the OS. The Windows 8/2012 defaults are usually sufficient under normal network load. However, under heavy network load it may be necessary to adjust these two registry settings to increase port availability and decrease the time to wait before reclaiming unused ports.

If the default limits are exceeded under heavier loads, the following error is observed "address in use: connect exception". To tweak, add/edit the following keys using regedit:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\ParametersMaxUserPort=65534 (DWORD, not in the registry by default, uses ports 1024-5000 by default. recommended: 16384 to 65534 decimal as necessary) -  maximum number of ports to use. 1024 is automatically subtracted from entered value to allow for reserved ports under 1024.

TcpTimedWaitDelay=30 (DWORD, not present in registry by default, 120 seconds when not present. Recommended: 30 decimal, denoting 30 seconds) - time to wait before reclaiming ports, in seconds. Default time before reclaiming ports, if value is at 0xffffffff or not present in the registry is 120 (or 240) seconds, depending on your OS. Just reducing the delay is often sufficient without changing MaxUserPort, as it allows for reusing ports more efficiently.

See:MSDN ms737757Technet MaxUserPort

QoS Reserved Bandwidth

The Windows "QoS Packet Scheduler" under Windows 8/8.1 (as with previous Windows versions) reserves 20% of bandwidth by default for QoS-aware applications that request priority traffic. Note this only has effect in the presence of running QoS applications that request priority traffic, like Windows Update, for example. To prevent QoS applications from getting priority to 20% of available bandwidth, customize the following registry setting:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\PschedNonBestEffortLimit=0 (DWORD, not present in the registry by default. When not present it reserves 20% of bandwidth. Recommended: 0 , possible values between 0 and 100) - indicates the percentage value of reserved bandwidth for QoS applications. Set to 0 to disable.

Notes:The NonBestEffort tweak applies only when the Windows Qos Packet Scheduler is enabled, and has effect ONLY in the presence of running QoS applications.QoS reserved bandwidth can also be disabled from the Gourp Policy Editor: Start -> Run: gpedit.msc -> open Local Group Policy Editor\Local Computer Policy\Computer Configuration\Administrative Templates\Network\QoS Packet Scheduler -> in the right pane, edit/enable "Limit reservable bandwidth" and reduce the percentage of "Bandwidth limit" to zero.

QoS Policy

QoS Policy settings under Windows 7/8 can be edited using the Group Policy Editor (gpedit.msc): Computer Configuration -> Windows Settings -> Policy-based QoS

In order to define DiffServ (DSCP) values, according to Microsoft the machine needs to have joined a domain, and interfaces have to see the domain controller. To overcome this limitation, so that you can tag DSCP values even for adapters that do not have access to a domain, use the following hidden registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\QoS (you may have to create the QoS key)"Do not use NLA"="1" (REG_SZ string value, not DWORD, not present by default, recommended: 1 if you plan to edit DSCP values via gpedit.msc)

Notes:gpedit.msc is only provided with the Professional/Ultimate and Server Windows variants.This registry key may also be needed in systems with multiple network adapters present.

Network Memory Allocation (Event ID 2017 error)

When using Windows to serve many/large files over the local network, it is possible to sometimes run into memory allocation errors related to the Windows share, especially with clients that use different operating systems. When this happens, you can usually see the following error in the Event Viewer System log:Event ID: 2017  "The server was unable to allocate from the system nonpaged pool because the server reached the configured limit for nonpaged pool allocations." It is also possible to get an error indicating that "Not enough server storage is available to process this command". To avoid those errors, you need to change the way Windows allocates memory for network services and file sharing. The below settings optimize the machine as a file server so it would allocate resources accordingly. There are two related registry settings:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory ManagementLargeSystemCache=1 (DWORD, default value: 0, recommended value: 1 for LAN file transfers, 0 for gaming)A value of zero establishes a cache of ~8 MB, a value of 1 allows the cache to expand up to the amount of physical memory minus 4 MB, as necessary. Reportedly some ATI video card drivers may have an issue with corrupt cache and degraded application performance when this is enabled, so we recommend to leave it off/zero for gaming.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\ParametersSize=3 (DWORD, default value: 1, recommended value: 3)minimizes used memorybalance used memoryoptimal setting for file sharing and network applications

Internet Explorer Web Browser Tweaks

MaxConnectionsPerServer / MaxConnectionsPer1_OServer Internet Explorer browser tweaks adjust the maximum number of concurrent connections your web browser can establish to any single website.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_MAXCONNECTIONSPER1_0SERVER\explorer.exe=10 (DWORD, default: 4, recommended: 8, valid range: 2-128)FEATURE_MAXCONNECTIONSPERSERVER\explorer.exe=10 (DWORD, default: 2, recommended: 8, valid range: 2-128)

In addition to explorer.exe, you can also add a 32bit DWORD "iexplore.exe" (according to MSDN), and set it to the same corresponding value as "explorer.exe"FEATURE_MAXCONNECTIONSPER1_0SERVER\iexplore.exe=10 (DWORD, not present by default, recommended: 8, valid range: 2-128)FEATURE_MAXCONNECTIONSPERSERVER\iexplore.exe=10 (DWORD, not present by default, recommended: 8, valid range: 2-128)

For more information, see our Web Browser Tweaks article

Note: Increasing this setting much over 10 can cause incomplete page loading and other issues with some pages.

Network Throttling Index (Gaming)

By default, Windows 8 continues to implement a network throttling mechanism to restrict the processing of non-multimedia network traffic to 10 packets per millisecond (a bit over 100 Mbits/second). The idea behind such throttling is that processing of network packets can be a resource-intensive task, and it may need to be throttled to give prioritized CPU access to multimedia programs. In some cases, such as Gigabit networks and some online games, for example, it is beneficial to turn off such throttling all together for achieving maximum throughput.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfileNetworkThrottlingIndex=ffffffff  (DWORD, default: 10, recommended: 10 for media sharing, ffffffff for gaming and max throughput, valid range: 1 through 70 decimal or ffffffff to completely disable throttling)

It is only recommended to change this setting in saturated Gigabit LAN environments, where you do not want to give priority to multimedia playback. Reportedly, disabling throttling by using ffffffff can also help reduce ping spikes in some online games. Games that may be affected by this throttling: Source Engine games (TF2, Left 4 Dead, CS:S), HoN, CoD, Overlord series.

SystemResponsiveness (Gaming and Multimedia)

In Windows 8/8.1, just like with Windows 7, multimedia applications use the "Multimedia Class Scheduler" service (MMCSS) to ensure priritized access to CPU resources, without denying CPU resources to lower-priority background applications. However, this also reserves 20% of CPU by default for background processes, your multimedia streaming and some games can only utilize up to 80% of the CPU. This setting, in combination with the above "NetworkThrottlingIndex" can help some games and video streaming. We recommend reducing the reserved CPU for background processes from the default of 20%.

Navigate to:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfileSystemResponsiveness=10 (DWORD, default is 20 denoting 20% of CPU reserved, recommended: decimal 10, or 0 for pure gaming/multimedia performance)

Notes: The number in this key is rounded by MMCSS to the nearest 10. In some server operating systems (Windows 2008 Server), the SystemResponsiveness may be set to 100, instead of 20 by default. This is by design, giving higher priority to background services over multimedia.

See also: MSDN ms684247

Disable Nagle's algorithm (Gaming)

Nagle's algorithm is designed to allow several small packets to be combined together into a single, larger packet for more efficient transmissions. While this improves throughput efficiency and reduces TCP/IP header overhead, it also briefly delays transmission of small packets. Disabling "nagling" can help reduce latency/ping in some games. Keep in mind that disabling Nagle's algorithm may also have some negative effect on file transfers. Nagle's algorithm is enabled in Windows by default. To implement this tweak and disable Nagle's algorithm, modify the following registry keys.

This setting configures the maximum number of outstanding ACKs:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{NIC-id}There will be multiple NIC interfaces listed there, for example: {1660430C-B14A-4AC2-8F83-B653E83E8297}. Find the correct one with your IP address listed. Under this {NIC-id} key, create a new DWORD value:TcpAckFrequency=1 (DWORD value, not present by default interpreted as 2, 1=disable, 2=default, specifies number of outstanding ACKs before ignoring delayed ACK timer). For gaming performance, recommended is 1 (disable). For pure throughput and data streaming, you can experiment with small values over 2. Wifi performance may see a slight improvement with disabled TcpAckFrequency as well.

In the same location, add a new DWORD value:TCPNoDelay=1 (DWORD value, not present by default, 0 to enable Nagle's algorithm, 1 to disable)

To configure the ACK interval timeout (only has effect if nagling is enabled), find the following key:TcpDelAckTicks=0  (DWORD value, not present by default interpreted as 2, 0=disable nagling, 1-6=100-600 ms). Note you can also set this to 1 to reduce the nagle effect from the default of 200ms without disabling it.

For Server Operating Systems that have Microsoft Message Queuing (MSMQ) installed, or if you have the MSMQ registry hive present, also add TCPNoDelay to:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\ParametersTCPNoDelay=1 (DWORD, not present by default, 0 to enable Nagle's algorithm, 1 to disable)

See also: Gaming Tweaks article

SG TCP Optimizer (version 4 Beta)

The SG TCP Optimizer is a free program that allows for easy tweaking of all the above TCP/IP settings for broadband with a couple of clicks. Note that only version 4 of the prorgam supports Windows 8 (and newer) and works with PowerShell cmdlets. There program is available in our downloads section.

The SG TCP Optimizer is a standalone application that does not require installation, you can just save it to the desktop, right-click -> choose "Run as administrator", and apply the "optimal" settings, or customize them to your liking. More detailed information about all available options is provided in the TCP Optimizer documentation, answers to frequently asked questions are available in the Optimizer FAQ, and personalized help is available through our forums.

References

Technet - Network Adapter CmdletsTechNet set-NetTCPSettingMSDN MSFT_NetTCPSetting classIncreasing TCP Initial congestion Window in Windows 2008 Server R2MS Hotfix for netsh errors in Windows Server 2008 R2 - MSKB 2472264

See Also

Windows 8 FAQsWindows 7, Vista, 2008 TweaksFirefox / Internet Explorer Browser Tweaks

NotesSome templates/settings, as well as changing the default NetTransportFilter are no longer editable in client Windows versions (Windows 8, 8.1), only Server variants (Server 2008, Server 2012/2012 R2).

The tweaks were tested and confirmed to work with Windows 10 Technical Preview build 10041.

Feedback and suggestions are always appreciated.

www.speedguide.net

SG :: TCP Optimizer 2 Documentation

2011-06-01 (updated: 2015-05-07) by Philip

This documentation is for version 2.x and 3.x of the TCP Optimizer under Windows XP/2000/2003. See the TCP Optimizer 4 Documentaton for Windows versions 7, 8, 2012, 10. Please also see the TCP Optimizer FAQ for answers to frequently asked questions.

Table of Contents

1. Introduction2. Using the program3. General Settings    3.1 Connection Speed slider    3.2 Network Adapter selection    3.3 TCP Receive Window    3.4 MTU Discovery    3.5 Black Hole Detect    3.6 Selective ACKs    3.7 Max Duplicate ACKs    3.8 Time to Live    3.9 TCP 1323 Options

4. Advanced settings    4.1 Internet Explorer Optimization    4.2 Host Resolution Priority    4.3 Type/Quality of Service    4.4 DNS Error Caching    4.5 LAN Browsing speedup    4.6 LAN Request Buffer Size

5. Largest MTU6. BDP7. Latency8. Registry9. Menus

    9.1 File Menu    9.2 Preferences Menu

Appendix A - EULA

Appendix B - Program Changes

1. Introduction

The TCP Optimizer is a program designed to provide an easy, intuitive interface for tuning TCP and IP related parameters in the Windows Registry. It takes into account all related RFCs, the Microsoft TCP/IP implementation oddities, verifies all Registry locations for the same TCP/IP parameters (ICS Sharing, AOL protocol MTU, etc), only ads the necessary Registry parameters, and overall aids in making the whole "tweaking for speed" experience a breeze. It is downloadable from here: SG TCP Optimizer.

In the following chapters, you will find short descriptions of all the settings and all aspects of the functionality of the TCP Optimizer. In addition to this documentation, you can also check the TCP Optimizer FAQ, as well as the SG Tweaking forum. We'd also appreciate any feedback about the program, please contact the webmaster or post in our forums with any suggestions for additions or changes to either the program or this documentation.

2. Using the program

If you do not feel like reading the entire documentation below, or you simply need the tweaks NOW, without spending time in learning the meaning of all those settings, you can use the Optimizer by following these short instructions:

- Choose your maximum Connection Speed from the slider bar (the maximum available bandwidth, in kilobits per second)- Choose your Network Interface, or check to Modify All Network Adapters- Pick "Optimal settings" from the radio-buttons near the bottom of the program- Click on the "Apply changes" button and reboot

The Optimizer can do all the rest for you (including a backup of the current registry settings, so you can revert the changes if you wish). The new version of the program includes a preview of all changes after hitting the "Apply changes" button and before actually editing the Windows Registry.

You can also use the Optimizer to easily apply custom values, test with different settings, and learn a bit more about tweaking and TCP/IP in general. We strongly recommend getting familiar with the settings, and learning what aspects of your connection they affect first. Also, note that some of the program tabs (Largest MTU, BDP, Latency) can be used as a learning tool without making any changes to the Windows Registry.

The 3 radio buttons at the bottom of the program show the relevant "Current settings" as set in the Windows Registry, the Optimizer recommended "Optimal settings", or allow for "Custom settings" for the more advanced user to test with different values.

Please see the following chapters for definitions and detailed descriptions of all options in the TCP Optimizer.

Note: You should be logged in with an account with administrative privileges to be able to write to some of the Registry keys and use the program to its full potential.

3. General Settings

This tab contains all the important tweakable TCP/IP parameters.

Connection Speed (in kilobits per second) - you have to choose your maximum available bandwidth here. The Optimizer will base any "Optimal settings" recommendations on the connection speed you choose in this slider bar. Please note it is an approximation of your maximum available bandwidth, it does not have to be exact.

Network Adapter selection - you should have a list of all present network interfaces in the system. When you select an adapter, using this pull-down menu, its IP address will be shown in the lower-right of this section. Note you can also choose to modify all network adapters at the same time, or tweak without modifying any of their settings.

You also have the option to type a a custom MTU value (that will be used to recommend RWIN). Generally, MTU can safely be set at 1500, however some types of connections, and some routers use smaller values. It is only necessary to edit the MTU value in such special cases. For example, the maximum MTU value for Windows XP PPPoE encapsulation is 1480 (even though other PPPoE implementations can use as high as 1492).

Note: In some rare cases, it is possible that your desired network device is not correctly identified by the Optimizer. That does not affect the program performance much, and you should simply choose "Modify All Network Adapters" in such cases. We'd also appreciate you contacting us with the exact device, so we can improve the program.

TCP Receive Window (a.k.a. RWIN) - this buffer is the single most important factor in tweaking your TCP/IP parameters. A small RWIN value limits your maximum throughput (the server waits for acknowledgements of received packets), one much larger than needed by your connection can have a negative effect on your connection as well. Here is some history on RWIN, and all the considerations in choosing an "optimal" value:

Originally, when the TCP protocol was developed, there were only 16 bits in the TCP header reserved for the size of this buffer, allowing for a maximum value of 2^16 (65535, if you start counting from 0). With faster high-latency networks this value proved insufficient, and RFC 1323 introduced additional "TCP Options", allowing for larger RWIN values. It is accomplished by bit shifting, or multiplying the original unscaled RWIN value (up to 65535 bytes) in the TCP header by a scale factor, power of 2.

The TCP Optimizer recommends an optimal TCP Window value considering all the following factors:

- Bandwidth * Delay product based on the chosen maximum connection speed and maximum anticipated latency.- RWIN (both scaled and unscaled) multiple of MSS, for maximum optimization.- Proper RFC 1323 scaling for RWIN values larger than 65535.- largest optimal unscaled RWIN (MSS multiple) used for all RWIN values over 65535.

MTU Discovery (RFC 1191, EnablePMTUDiscovery) - We recommend enabling (choosing "Yes") this setting.MTU Discovery determines whether TCP uses a fixed, default maximum transmission unit (MTU) or attempts to find the actual MTU. In some versions of Windows, if MTU Discovery is disabled the OS uses an MTU of 576 bytes for all connections to computers outside of the local subnet. If enabled, TCP attempts to discover the MTU (largest packet size) over the path to a remote host.

Black Hole Detect (EnablePMTUBHDetect) - The recommended optimal setting in the TCP Optimizer is "No".Enabling this setting causes TCP to try to detect black hole routers while doing Path MTU Discovery. A black hole router does not return ICMP Destination Unreachable messages when it needs to fragment an IP datagram with the Don't Fragment bit set. TCP depends on receiving these messages to perform Path MTU Discovery. With this feature enabled, TCP tries to send segments without the Don't Fragment bit set if several retransmissions of a segment go unacknowledged. If the segment is acknowledged as a result, the MSS is decreased and the Don't Fragment bit is set in future packets on the connection. Enabling black hole detection increases the maximum number of retransmissions that are performed for a given segment. Unless you are dealing with a relatively archaic network, or running a server, this setting does not make much visible difference, and can in fact waste bandwidth if enabled.

Selective ACKs (SackOpts) - the recommended setting is "Yes".This parameter controls whether or not SACK (Selective Acknowledgement) support is enabled, as specified in RFC 2018. SACK is especially important for connections using large TCP Window sizes.

Max Duplicate ACKs (TcpMaxDupAcks) - range is 1-3, the recommended value is 2.This parameter determines the number of duplicate ACKs (acknowledgements) that must be received for the same sequence number of sent data before "fast retransmit" is triggered to resend the segment that has been dropped in transit.

Time to Live (TTL, DefaultTTL) - recommended value is 64.This setting specifies the default time-to-live (TTL) value set in the header of outgoing IP packets. The TTL determines the maximum amount of time in seconds (and the number of hops) that an IP packet may live in the network without reaching its destination. It is effectively a limit on the number of routers that an IP packet is allowed to pass through before being discarded. It does not directly affect speed, however a value that's too small can cause packets to be unable to reach distant servers at all. A very large value, on the other hand might take too long to recognize lost packets.

TCP 1323 Options (TCP1323Opts) - we recommend having only "Window Scaling" enabled.This parameter controls RFC 1323 time stamps and window-scaling options. The "Window Scaling" part allows for RWIN (TCP Window) values over 65535. Timestamps add another 12 bytes to the header of each packet, and are only necessary in connections with increased packet loss.

4. Advanced Settings

This tab contains additional tweaks, that have a smaller, but still noticeable effect on TCP/IP performance. Generally, the tweaks on this page are not directly related to throughput. Some of the tweaks in this section of the Optimizer might be related only to specific aspects of networking, such as Web, or LAN browsing, hostname resolution speed, etc.

Internet Explorer OptimizationBy default, the HTTP 1.1 specs allow for only 2 concurrent connections to a Web server. That means, while downloading a web page you can only get 2 files at a time. Note that a single page usually includes tens (sometimes hundreds) of images, each initiating a separate request to the server. Increasing the default to ~10 can provide a considerable visible boost in web page loading time, especially for broadband internet connections. There are two parameters in this section, MaxConnectionsPerServer, and MaxConnectionsPer1_0Server, corresponding to HTTP 1.1 and 1.0, respectively. We recommend setting both to the same number, between 4 and 10.

Host Resolution PriorityThis section improves DNS and hostname resolution in general. It helps web pages load faster, and has negligible effect on downloads. For more information on what/how this tweak operates, check our Host Resolution Priority Tweak article. We recommend using the Optimal values (5,6,7,8).

Type/Quality of ServiceQoS (Quality of Service) and ToS (Type of Service) have to do with support for priority traffic.

QoS is enabled by default in Windows XP, and can limit available bandwidth in order to accommodate high-priority traffic, when present. The Optimizer only changes the QoS value if it is already present in the registry. It is in the Registry only if the QoS Packet Scheduler is installed (can be added from the Network Adapter Properties). We recommend having the QoS Packet Scheduler uninstalled, or/and setting the QoS: NonBestEffortLimit Optimizer setting to 0%.

ToS (Type of Service, RFC 791, RFC 1812) is a field of the IP header, designed to also carry quality of service features, such as prioritized delivery for IP datagrams. It is not widely used, and it has been redefined and superseded by a newer standard called Differentiated Services (DiffServ) and defined in  RFC 2474 , RFC 2475, RFC 2597, RFC 2598. DiffServ increases the number of definable priority levels by reallocating bits of an IP packet for priority marking. The TCP Optimizer allows for ToS/DiffServ editing, although it is an advanced setting, probably beyond the scope of regular residential broadband tweaking. If you feel comfortable editing this value, you might also want to note possible conflicts with using some ToS values in a DiffServ environment, as described in RFC 2873.

ToS other than 0 is only available if ToS: DisableUserTOSSetting is present, and set to "0" in the Optimizer. If enabled, the ToS: DefaultTOSValue can be set to a specific number, (which is probably beyond the scope of this help file, but is somewhat explained below - feel free to read the related RFCs referenced above for more info). If we must make a recommendation, here are some good DefaultTOSValue numbers that are valid, and with high precedence in both ToS and DiffServ environments:

  1. DefaultTOSValue = 80 - (010 100 00 binary). This setting should be tried first. It is not very aggressive, but it takes precedence over regular traffic and asks for low delay. For ToS, you get immediate precedence, low delay. For DiffServ, you get AF22 - class 2 traffic, medium drop probability.
  2. DefaultTOSValue = 136 - (100 010 00 binary). This is a moderately aggressive precedence setting. For ToS, you get flash override precedence, high throughput. For DiffServ, you get AF41 - class 4 traffic, low drop probability.
  3. DefaultTOSValue = 184 - (101 110 00 binary). This is a very aggressive setting, that might introduce some packet loss - it is usually only recommended for audio/video applications. For ToS, you get critical precedence, low delay, high throughput. For DiffServ, you get EF - Expedited Forwarding, high priority traffic, but with higher drop probability.

The tables below explain the ToS and DiffServ values in more detail so you can choose your own numbers

ToS Field in Detail:

bit 01234567
Precedence

000 (0) - routine001 (1) - priority010 (2) - immediate011 (3) - flash200 (4) - flash override101 (5) - critical110 (6) - Internetwork Control111 (7) - Network Control

Delay

0 - normal1 - low

Throughput

0 - normal1 - high

Reliability

0 - normal1 - high

Cost

0 - normal1 - low

MBZ

checking bit(Must Be Zero)

Note: The field is 8 bits in the IP header, first 3 define precedence, then one each for delay, throughput, reliability, cost and a checking bit as illustrated by the table above.

DiffServ Field:

bit 01234567
DSCP (Differentiated Services Codepoint) Class selection is in the first 3 bits, and maps directly to the IP Precedence bits from the ToS table above.CU Currently unused, best kept at 00 for backward compatibility with ToS.

DiffServ Codepoints (first 6 bits) in order of precedence:

NameCodepoint(CU)DiffServ(decimal)RFC#Notes
CS0000 000 (00)02474class 0, default (routine)
CS1001 000 (00)322474class 1 - similar to the ToS Precedence (priority)
AF11 001 010 (00)40 2597 AF (Assured Forwarding) class 1 - low drop precedence
AF12 001 100 (00) 48 2597 AF class 1 - medium drop precedence
AF13 001 110 (00) 56 2597 AF class 1 - high drop precedence
CS2010 000 (00)642474class 2 - similar to the ToS Precedence (immediate)
AF21 010 010 (00) 72 2597 AF class 2 - low drop precedence
AF22010 100 (00)802597 AF class 2 - medium drop precedence
AF23 010 110 (00) 88 2597 AF class 2 - high drop precedence
CS3011 000 (00)962474class 3 - similar to the ToS Precedence (flash)
AF31 011 010 (00) 104 2597 AF class 3 - low drop precedence
AF32 011 100 (00) 112 2597 AF class 3 - medium drop precedence
AF33 011 110 (00) 120 2597 AF class 3 - high drop precedence
CS4100 000 (00)1282474class 4 - similar to the ToS Precedence (flash override)
AF41 100 010 (00) 136 2597 AF class 4 - low drop precedence
AF42 100 100 (00) 144 2597 AF class 4 - medium drop precedence
AF43 100 110 (00) 152 2597 AF class 4 - high drop precedence
CS5101 000 (00)1602474class 5 - similar to the ToS Precedence (critical)
EF PHB 101 110 (00) 184 2598 Expedited Forwarding (recommended for video/audio - high priority, higher drop probability)
CS6110 000 (00)1922474class 6 - similar to the ToS Precedence (Internetwork Control)
CS7111 000 (00)2242474class 7 - similar to the ToS Precedence (Network Control)

Notes:- The DiffServ column shows the 8-bit decimal equivalent that should be used in the TCP Optimizer for the "DefaultTOSValue". The value is obtained by appending two 0s to the 6-bit DiffServ codepoints. Note to set any ToS other than 0 in the Optimizer, you also need to set "DisableUserTOSSetting" to "0" (non-empty zero value).- Higher class traffic takes precedence. Values not in the above table can get reset to the default (0), or have the connection reset.- Some routers may change, or reset the ToS/DiffServ value to 0 regardless of the setting.

DNS Error CachingWindows has built-in DNS (Domain Name System) caching, which basically caches resolved hostnames for faster access and fewer DNS lookups. This is generally a great feature, with the only downside that failed DNS lookups get cached by default as well... When a DNS lookup fails (due to temporary DNS problems), Windows still caches the unsuccessful DNS query, and in turn fails to connect to a host regardless of the fact that the DNS server might be able to handle your lookup seconds later. One can manually flush failed DNS lookups by typing ipconfig /flushdns in Command prompt... Or you can simply set the 3 values in the Optimizer to "0", and it will set the relevant Registry settings.

Note:  Seems Microsoft changed the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\NegativeCacheTime Registry entry in Windows 2000to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\MaxNegativeCacheTtl in Windows XP and 2003 server. We have updated this in the 2.02 version of the program.

LAN Browsing speedup (disabling the Network Task Scheduler)This tweak disables searching networked computers for scheduled tasks (when set to "Optimized" in the program). It reduces the long wait when opening network folders, and speeds up LAN browsing.

LAN Request Buffer Size (reduces network delay)In higher latency Networks, delays may be encountered with the default request buffer size (4356 decimal). The range of this parameter is 1024 - 65535 bytes. Testing has shown that, in most standard Ethernet environments, if memory is available 16384 bytes is a better choice. This tweak only applies to LANs, and helps with slow browsing of large directories.

5. Largest MTU

This section aids in finding the largest possible non-fragmented packet between your PC, and a server. You can specify an URL, click Start, and have the program ping the specified server with different packet sizes, until it finds the largest possible packet before fragmentation occurs. The largest non-fragmented MTU is important in that it represents the optimal MTU value on that particular path.

A large MTU value helps in maximizing data vs. header size for a particular data segment. Fragmentation and reassembling of packets can cause slowdowns, and introduces more header overhead as well. That is why the largest non-fragmented MTU value for your network connection is a significant factor in tweaking. Once the program finds the largest non-fragmented packet, it can be plugged in the MTU value in the General Settings tab.

Note that for this to work, it is best to set your MTU value to 1500 temporarily, since the largest non-fragmented MTU us also bound by the MTU value on your end.

6. BDP (Bandwidth * Delay Product)

This section contains a Bandwidth * Delay calculator. The BDP is a very important concept in TCP/IP Networking. It is directly related to the TCP Window (RWIN) value, in that it represents a limit to the possible throughput. BDP plays an especially important role in high-speed / high-latency networks, such as most broadband internet connections. It is one of the most important factors of tweaking TCP in order to tune systems to the type of network used.

The Bandwidth*Delay Product, or BDP for short determines the amount of data that can be in transit in the network. It is the product of the available bandwidth and the latency, or RTT.

The BDP simply states that:

BDP (bits) = total_available_bandwidth (bits/sec) x round_trip_time (sec)

or, since RWIN/BDP is usually in bytes, and latency is measured in milliseconds:

BDP (bytes) = total_available_bandwidth (KBytes/sec) x round_trip_time (ms)

What does in all mean ? The TCP Window is a buffer that determines how much data can be transferred before the server waits for acknowledgement. It is in essence bound by the BDP. If the BDP (or RWIN) is lower than the product of the latency and available bandwidth, we can't fill the line since the client can't send acknowledgements back fast enough. A transmission can't exceed the (RWIN / latency) value, so RWIN needs to be large enough to fit the maximum_available_bandwidth x maximum_anticipaded_delay.

7. Latency

This section of the program is simply a tool for testing the latency of your network/internet connection. You can choose a number of hosts, a number of pings per host, and ICMP packet size. After clicking start, the tool will consecutively ping all hosts, then provide maximum and average latency measurements in milliseconds, as well as packet loss indication (if present).

This tool can be used to effectively estimate the maximum anticipated latency for BDP/RWIN calculations. In order to do that, we recommend using a larger number of hosts than the default 5, and a larger packet size (since larger packets tend to have a bit higher latency). Then, as an estimate of your maximum anticipated latency, rather than using the Maximum RTT, use the average RTT, multiplied by two.

Notes:

  • Pinging hosts uses ICMP, rather than TCP. Some routers give very low priority to ICMP traffic, and as a result you may experience a higher percentage of packet loss.
  • Larger packets have a bit higher latency
  • RTT varies with time of day, network congestion, etc.
  • Some nodes might choose to drop repeated ICMP requests when congested, or ignore them all together.

8. Registry

This section of the Optimizer has been improved to include an actual Registry Editor. It is a direct interface to the Windows Registry, and only intended for advanced use ! Please only use it carefully, and at your own risk.

Note that the Registry editor only includes TCP/IP, and some related hives of the Windows Registry.

To use it, simply navigate to the appropriate key you wish to edit in the left section of the editor, then work in the right section, by either choosing a value/key and editing it, or adding a new one. All available actions for the currently active window/key/value are reachable by right-clicking on them.

9. Menus

The File Pull-down menu contains a number of options for backing up, as well as exporting and importing all the related TCP Optimizer settings. Those options can be shared between users, they contain information about empty keys, values to remove/add/edit and all relevant parameters to clone the exact state of the related settings to another machine, or save them for your own reference later.

The Preferences menu, pictured on the right has two sections. The first one, "Maximum Latency" is a number in milliseconds, that is used in calculating the optimal RWIN value. It affects all the "Optimal settings" recommendations of the program, so if you're not sure what it does, leave it at the default 500ms. Basically, the larger this number, the larger RWIN values the program is going to recommend under "Optimal settings" for the same connection speed, and vice versa.

The second section in the Preferences menu, "Latency tab: hosts to ping" contains a list of URLs, used in the Latency section of the program for measuring current RTT (round trip time, delay, ping, latency) to multiple hosts.

The Help Menu of The Optimizer simply contains a link to this documentation, as well as the Software License Agreement, and some general information about the program.

Appendix A - EULA

By downloading, using, copying and (re)distributing the TCP Optimizer, you agree to the Software End User License Agreement, incorporated here by reference.

Appendix B - Program Changes

See: TCP Optimizer Revision History

__________________Documentation version 2.0.7 Last updated 2015-04-19 Note: some of the screenshots/information may not pertain to all OSes supported by the program.

www.speedguide.net

SG :: TCP Optimizer Revision History

2015-04-04 (updated: 2016-09-07) by Philip

The SG TCP Optimizer can be downloaded from our downloads section. Documentation for the latest version of the program is available here: SG TCP Optimizer 4 Documentation

TCP Optimizer v. 4.0.6 (2016.09.07)

  • Changed recommended optimal TCP Auto Tuning level from "experimental" to "normal" for fast connections over 100 Mbps to avoid some LAN shares issues
  • Updated recommended optimal TCP Auto Tuning level from "restricted" to "disabled" for connection speeds under 512 Kbps.

TCP Optimizer v. 4.0.5 (2016.05.03)

  • Minor update that only affects custom advanced settings. Fixed a bug where a couple of advanced settings would not be deleted in custom mode if dialog is left empty by the user.

TCP Optimizer v. 4.0.4 (2016.03.15)

  • Changed "optimal" recommendation for "TCP Chimney Offload" to "disabled" due to the setting causing issues with some servers and now considered deprecated by Microsoft. See: Obsolete RFCs and Overview of TCP Timers

TCP Optimizer v. 4.03 (2015.10.27)

  • Changed "current" state under Windows 8/10 to display empty lines for dialogs that are not read at program start to avoid confusion

TCP Optimizer v. 4.02 (2015.10.12)

  • Fixed a minor bug to correctly read current "InitialRTO" and "MinRTO" advanced settings under Windows 8.1/10

TCP Optimizer v. 4.01 (2015.09.25)

  • Updated OS detection algorithm to make the program more robust. Unknown OS versions will assume the latest supported (currently Windows 10)

TCP Optimizer v. 4.00 Beta (2015.04.20):

  • Updated OS detection for Windows 8, 8.1, 10, 2012 Server, 2012 Server R2, Windows 10
  • Updated all settings that work with Windows 8,8.1,2012 Server, 2012 Server R2, Windows 10
  • Fixed MaxConnectionsPerServer (switched HTTP 1.0 and 1.1 setting) and updated optimal from 8 to 10 connections
  • Changed NetDMA "optimal" state for Windows 7, disabled unsupported setting for Windows 8 and later
  • Added PowerShell cmdlets handling for Windows 8/8.1/2012/10 support
  • Added all new relevant tweaking options under Windows 8 and newer.
  • Added new TCP Offload tweakable parameters
  • Added the "SystemResponsiveness" gaming tweak
  • Updated reset of TCP/IP and Winsock for Windows 8/2012
  • Reordered the settings for more consistent appearance across newer OSes (Windows Vista and newer)
  • Updated Nagle's Algorithm Registry hive to include a second location
  • Reduced optimal TCP Max Data Retransmissions to 5
  • Added "Create Log" checkmark to "Apply Settings" dialog that logs all executed commands by the program
  • Updated default URLs in "Preferences" menu to ones that respond to ICMP pings.
  • Updated unsupported settings for Windows 8 and newer: SynAttackProtect,TCPMaxDataRetransmissions, replaced with relevant PowerShell cmdlets
  • Removed for Windows 8 and newer: NetDMA, DNS Error Caching
  • Some bug fixes and minor internal improvements
  • 2015.04.28 - updated backup/restore menus
  • 2015.04.28 - added MTU IPv6 support for Windows 7 and newer
  • 2015.04.28 - fixed MTU setting for Windows 8/8.1/10/2012
  • 2015.04.29 - updated Nagle's algorithm tweak to include more options
  • 2015.04.29 - fixed TCPNoDelay and TcpDelAckTicks reading of "current" values.
  • 2015.04.30 - changed to multithreaded mode for reading of PowerShell cmdlets with Windows 8 and newer.
  • 2015.04.30 - updated initial loading dialog to be more informative and show executed commands under Windows 8 and newer (necessary because of PowerShell cmdlets delay).
  • 2015.04.30 - changed per adapter Large Send Offload (LSO) current reading for IPv4.
  • 2015.05.19 - updated Windows default SystemResponsiveness for Windows 2008/2012 Server from 20 to 100.
  • 2015.05.19 - added "Do not use NLA" QoS option to allow setting DSCP values without the need to join a domain, and for multiple NICs.

TCP Optimizer v. 3.0.8 (2011.09.17):

  • Added NetworkThrottlingIndex gaming tweak to the Advanced tab
  • Changed "MaxUserPort" optimal value from 65535 to 65534.
  • minor internal improvements

TCP Optimizer v. 3.0.7 (2011.03.22):

  • Improved international Windows support (MTU should be correctly recognized and modified for most countries/network adapters)
  • Increased MTU limit to 9000 to accomodate some Gigabit connections
  • Changed ECN Capability optimal recommendation in General tab based on user feedback and issues with some US ISPs
  • Fixed a minor issue with TcpAckFrequency and TcpDelAckTicks not applied only in "custom" mode in some cases where the Network adapter is not recognized

TCP Optimizer v. 3.0.6 (2010.10.06):

  • fixed a possible program crash condition under Windows 2008 Server R2
  • added traceroute capability to the MTU/Latency tab
  • improved netsh current settings reading under Swedish versions of Windows

TCP Optimizer v. 3.0.5 (2010.09.16):

  • fixed a 3.x Windows XP bug - only when choosing to "modify all network adapters", two advanced settings (TcpAckFrequency and TCPDelAckTicks) were set incorrectly.
  • Improved International Windows support (reading current netsh settings).
  • minor internal improvements

TCP Optimizer v. 3.0.4 (2010.09.06):

  • Improved International Windows support - netsh current settings in the General tab should now be read correctly for many languages
  • minor internal improvements

TCP Optimizer v. 3.0.3 (2010.07.29):

  • changed 64-bit OS handling to avoid 32-bit access issues causing some netsh settings not to remain persistent after reboot
  • changed Direct Cache Access (DCA) and NetDMA (TCPA) handling in Windows 7
  • minor internal improvements

TCP Optimizer v. 3.0.2 (2010.07.12):

  • added "Dynamic port allocation" (MaxUserPort, TcpTimedWaitDelay) for Windows XP/2003
  • added "Checksum Offloading" (DisableTaskOffload) setting for Windows 7/Vista/2008/XP/2k3
  • added a "Copy current settings" option to the File menu for easy sharing of current settings (forum posting, etc.)
  • fixed incorrect error message under Chinese versions of Windows 7 x86.

TCP Optimizer v. 3.0.1 (2010.07.09):

  • fixed reading current settings correctly under XP
  • temporarily disabled incorrect error message under Windows 7 x64 after applying changes
  • Enabled Gaming tweak (disable Nagle's algorithm) in Windows XP mode
  • minor cosmetic/message updates

TCP Optimizer v. 3.0 (RC1, 2010.07.07):

  • complete rewrite of the General tab to support Windows 7, Vista, and Server 2008 - different look and settings under Windows 7/Vista vs. XP/2k
  • increased connection speed slider to 100+ Mbps
  • added an easier method to revert to the Windows default settings per OS version
  • added options to reset TCP/IP and Winsock
  • Combined Latency and BDP tabs into one, updated Largest MTU algorithm and sites to ping
  • various minor improvements

Known issues: when applying some custom settings, you may see an error: "Set global command failed on IPv4 The parameter is incorrect". The settings are being applied (can be verified by restarting the Optimizer and checking "current" settings), just the error is incorrectly displayed.

Changes in TCP Optimizer v. 2.0.3 :

  • Under Optimal or Custom mode, when PPPoE is checked, and the MTU is not modified manually, the displayed 1492 MTU is now correctly applied to the Registry.
  • If MTU is set to a value outside the valid range, and the user changes current/optimal/custom mode, the value is now properly reset to 1500.
  • The Latency tab will account for, and discard incorrect negative RTT values sometimes returned by servers. Such values will no longer count towards the min/max/avg calculations.

Changes in TCP Optimizer v. 2.0.2 :

  • Added all virtual Network Adapters to the list of NICs.
  • Changed the NegativeCacheTime Windows 2000 entry to MaxNegativeCacheTtl for Windows XP and 2003 Server (DNS Caching).
  • Added Scaled RWIN and Tcp1323 Options for Windows 95 machines as requested (a MS update to Windows 95 is also necessary for this to work)
  • Removed the ToS/QoS control box frame, LAN Browsing speedup, and LAN Request Buffer size from Windows 9x Advanced settings.
  • Changed custom mode to display the current values by default, rather than optimal ones.
  • Fixed the Windows 9x Advanced settings optimal/custom modes to display the correct Host Resolution Priorityy
  • Fixed the RWIN calculation to take into account custom latency selection after program restart.
  • Updated the Windows 9x RWIN calculation to match the Windows XP/2k/2k3 algorithm

Changes in TCP Optimizer v. 2.0.1 :

  • Fixed a bug where DefaultTTL was set to "0" instead of "64" under "Optimal settings" in Windows 9x.
  • Fixed the "LAN Browsing speedup" to correctly show "Optimized" under current settings when applicable.
  • Changed "Connection speed" slider bar to accommodate faster broadband connections as per users' requests.
  • Changed "Connection speed" slider bar to retain last user-selected speed setting after program restart.

Changes in TCP Optimizer v. 2.0.0 (from version 1.0):

  • Added a new tab with a BDP (Bandwidth*Delay Product) calculator
  • Registry tab is now an editor, users can edit/add/delete keys in related hives.
  • Changed the connection speed to a more flexible slider bar.
  • Changed the RWIN calculation to reflect various speeds, optimal RWIN is now recalculated on the fly.
  • Added Afd check for the RWIN value, to avoid confusion with XP SP2.
  • Enabled custom MTU values under "Optimal settings."
  • Added check for AOL and PPPoE "Protocol MTU" for clients that have, or have had AOL installed.
  • Added QoS / ToS editing to the "Advanced settings" tab.
  • Added DNS error caching fix
  • Added Host Resolution Priority tweak
  • Added LAN "Request Buffer Size" tweak
  • Automatic backup of related registry keys before changing any values.
  • Expanded the import/export/backup capabilities.
  • Added "Preferences" to the program, users can now choose URLs for the Latency tab, as well as "maximum anticipated delay" for RWIN calculations.
  • Added a preview of changes, after clicking "Apply changes" and before they're actually applied.
  • Added documentation.
See Also:

TCP Optimizer DownloadTCP Optimizer 4 DocumentationTCP Optimizer FAQ

__________________

www.speedguide.net


Смотрите также