TCP Optimizer 4 Documentation - Windows 7, 8, 10, 2012-2019

Server
speedguide.net/articles/tcp-optimizer-4-documentation-windows-7-8-10-2012-5821

Home » Articles » TCP Optimizer

Login Articles
Please Login
Shortcuts
5000+ 2015-04-12 (updated: 2021-11-25) by Philip
Routers

1/19
65535
Ports
FAQs
Glossary
SG
Broadband
Tools
SG IP This documentation is for version 4 of the SG TCP Optimizer. The software
Locator supports Windows 7, 8, 8.1, 10 (including newer revisions), 2012 Server (including
R2), 2019 Server. Some of the settings may be specific to newer revisions of
SG
Network Windows, and not present in earlier versions. Please also see the TCP Optimizer
Tools FAQ for answers to frequently asked questions.
SG The TCP Optimizer documentation for Windows XP/2000/2003/NT (and TCP
Security Optimizer 2.x) is available -here-.
Scan
SG Speed
Test Table of Contents
TCP/IP
Analyzer 3.1 Connection Speed Slider
TCP/IP 3.2 Network Adapter Selection
Optimizer 3.3 TCP Window Auto Tuning
3.4 Windows Scaling heuristics
3.5 Congestion Control Provider
3.6 Receive-Side Scaling (RSS)
3.7 R.Segment Coalescing (RSC)
3.8 Direct Cache Access (DCA)
3.9 Time to Live (TTL)
3.10 ECN Capability
3.11 Checksum Offloading
3.12 TCP Chimney Offload
3.13 Large Send Offload (LSO)
3.14 TCP 1323 Timestamps
3.15 NetDMA (Windows Vista/7)

4. Advanced Settings
4.1 Internet Explorer Optimization
4.2 Host Resolution Priority
4.3 Retransmissions
4.4 Retransmit Timeout (RTO) - Windows 8 and newer
4.5 DNS Error Caching - Windows 7/Vista
4.6 Type/Quality of Service
4.7 Gaming Tweak - Network Throttling Index
4.8 Gaming Tweak - Disable Nagle's algorithm
4.9 Network Memory Allocation
4.10 Dynamic Port Allocation

Appendix A - EULA

1. Introduction

2/19
The TCP Optimizer is a program designed to provide an easy, intuitive interface for
tuning broadband-related TCP and IP related parameters under all current (and
some past) Windows versions. Version 4 of the TCP Optimizer supports all
Windows variants from XP/NT/2000/2003 through Windows Vista/7/2008 Server, to
the newer Windows 8, 2012 Server, as well as Windows 10. Some of the settings
under all those Operating Systems are quite different, and the program will show
only supported options for the detected Operating System it is running on. The TCP
Optimizer takes into account all related RFCs, the Microsoft TCP/IP implementation
oddities. verifies all relevant Registry locations for the same TCP/IP parameters,
uses PowerShell cmdlets with newer Windows versions, implements all tweaks
listed in our speed tweak articles, and, in general makes the whole "tweaking for
speed" experience a breeze.

Below, we will cover all the settings available in the TCP Optimizer. Some of the
settings may only be available under Windows 8 and newer operating systems.

2. Using the program - quick overview

If you do not feel like reading the entire documentation below, or you simply need
the tweaks NOW, just follow these short instructions:

Start the program with administrative permissions: right-click on the program,

choose "Properties" -> Compatibility tab -> tick "Run this program as an
administrator" -> OK
Choose your maximum connection speed (as advertised from your ISP) in the
slider bar.
Choose your Network Adapter that connects you to the Internet (or tick "Modify all
network adapters")
Pick "Optimal settings" from the radio-buttons near the bottom of the program
Click on the "Apply changes" button, choose to create backup and log, and
reboot when prompted

3/19
The TCP Optimizer can do all the rest of the work for you and optimize your internet
connection. A preview of all relevant changes is available before they are actually
applied. The program can be used to easily apply custom values, and test with
different settings, if you'd prefer. To do so, you may have to read the rest of the
documentation and our tweaking articles to understand what the different settings
mean, and what their exact effect is.

Please read the following chapters for information on all the specific parameters in
the program.

Note: You should be logged in with your main account (some settings are account-
specific), and run the program with administrative privileges so that it has sufficient
permissions to make all the necessary changes.

3. General Settings
Below is a short description of all the settings in the "General Settings" tab of the
TCP Optimizer under current Windows versions.

Connection Speed

This slider is intended for choosing your maximum possible internet connection
speed, as advertised by your Internet Service Provider (ISP). You should not use
your current speed, or any speed test results here, rather what the maximum
theoretical speed of your connection is. Note that speed is expressed in Mbps,
denoting Megabits per second (not to be confused with Megabytes).

Changing the value in the connection speed slider will have some effect on the
optimal TCP Window value. Under older Windows variants, it directly calculates the
RWIN value optimal for the connection speed. Under newer Windows OSes, it may
change the auto-tuning algorithm (restricted for speeds under 1Mbps, normal for
most broadband connections, experimental for speeds over 1 Gbps, to be used with

4/19
caution currently). Note that the "experimental" TCP Window auto-tuning setting
should be used with caution, as it may cause some stability issues. Reportedly it
may cause issues with Outlook connecting to mail servers, accessing local network
shares, and Crashplan backups in some Windows versions.

Network Adapter selection

A list of all present/active network interfaces recognized by the system. If a specific
network adapter is selected using the pull-down menu, its IP address will be
displayed in the lower-right portion of this section. You can also choose to modify all
network adapters at the same time, or none of their individual setting.

This section allows you to set a custom MTU value. Generally MTU should be set at
1500, with the exception of PPPoE connections, and some DSL modems/ISPs. It is
only necessary to edit the MTU value in such special cases. For example, the
maximum MTU value for Windows PPPoE encapsulation is 1480 (or, as high as
1492 in some cases).

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 your feedback with such devices, so that we can improve the
program.

TCP Window Auto Tuning

This setting tunes the TCP Receive Window auto-tuning algorithm in Windows. A
small TCP Receive Window can limit high-speed, high-latency transfers, such as
most broadband internet connections. We recommend setting this to "normal" for
most connections, and, make sure that you disable "Windows Scaling heuristics"
below so that Windows does not automatically modify this parameter.

There are a couple of exceptions to setting TCP auto tuning to "normal":

1. If your connection speed is less than 1 Megabit per second, you can set it to
"highlyrestricted".
2. If you are on dial-up connection, you can try setting this to "disabled" (as your
speed will not need buffers larger than 64KB).
3. If your connection speed is near/over 1 Gigabit (1000 Mbps), you can try setting
this to "experimental". This should be tested further, however, as it may cause some
stability issues. If you experience any issues with the "experimental" setting please
dial it back to "normal" and share your experience on the forums or via email.

Windows Scaling heuristics

If this is left enabled, Windows can restrict the TCP Receive Window at any point in
time it decides that the network conditions justify it. When Windows restricts the
TCP Receive Window, it does not always return to normal. It is highly recommended
to set this parameter to "disabled", so that user-set TCP auto tuning settings are
retained over time.

5/19
Congestion Control Provider
Traditionally, TCP avoids network congestion by gradually increasing the TCP Send
Window at the beginning of connections. With broadband connections, these
algorithms do not increase the TCP Window fast enough to fully utilize the available
bandwidth. 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.

This should be set to "CTCP" in most common scenarios, "CUBIC" is also a good
choice with newest Windows builds.

CTCP (Compound TCP) increases the TCP Receive Window and amount of data
sent. It can improve throughput on higher latency and broadband internet
connections. CTCP uses estimates of queue delay as a measure of congestion, and
allocates buffers accordingly.

DCTCP (Data Center TCP) adjusts the TCP Window based on network congestion
feedback based on Explicit Congestion Notification (ECN) signaling. It may improve
throughput on low latency/local links. Note that this setting may only work on Server
Operating System variants.

New Reno (TCP New Reno RFC 3782, RFC 6582) is based on the old "Reno"
congestion control algorithm. New Reno treats retransmission timeouts (RTO) and
duplicate ACKs as packet loss just like the older Reno, Tahoe) algorithms, however
it performs a fast retransmit and skips the slow start and enters "fast recovery". It is
actual congestion-based, rather than delay-based algorithm. The algorithm has
some issues with out-of-order packets (by more than 3 packet sequence numbers).

CUBIC is a newer congestion control algorithm optimized for high bandwidth/high

latency networks. The algorithm does not rely on the receipt of ACKs to increase the
TCP window size, it is only dependent on the last congestion event. With traditional
algorithms, connection flows with very low latency have advantage as they receive
ACKs much faster, and their buffers (congestion window) grow faster. The CUBIC
algorithm allows for more "fairness" between flows with low and high latency, as the
TCP Window of the different connections is independent of RTT. CUBIC is the
default algorithm for newer Linux kernels, and in Windows 10 since version 1803
(April 2018). It is a welcome change, CUBIC provides good support for high
bandwidth/latency networks by allocating large TCP buffers at the line saturation
point. It should in theory provide a more stable connection when the network is fully
utilized, at the expense of a bit larger buffers. CUBIC provides a bit more "fair"
buffer regardless of RTT. There are no noticeable gaming/latency improvements
over CTCP, however, CUBIC should work better for pure throughput and in the
presence of multiple connections with various latencies.

Receive-Side Scaling (RSS)

RSS enables parallelized processing of received packets on multiple processors,
while avoiding packet reordering. It separates packets into "flows" and uses different
processors for processing each flow.

6/19
This should be enabled if you have two or more physical processor cores, and only
has an effect if the Network Adapter, as well as the NIC driver can handle RSS. If
the NIC driver has a "Queue Size" setting, it should be set to a number less than, or
equal to 4, and no greater than the number of available physical processor cores.

R.Segment Coalescing (RSC)

Receive Segment Coalescing allows the Network adapter to coalesce multiple
TCP/IP packets that arrive within a single interrupt into larger packets (up to 64KB)
so that the network stack has to process fewer headers. This reduces I/O overhead
and CPU utilization.

This should be disabled for gaming/latency, and only enabled for pure throughput
when CPU overhead is an issue. Not recommended for media servers, web/mail
servers, or Wi-Fi adapters.

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).

Recommended: enabled with Gigabit network adapters and hardware that supports
it.

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

Time to Live (TTL)

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.

Recommended value is 64

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.

7/19
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.

Recommended: disabled in general. Enable with caution, because some routers

may drop packets with the ECN bit set and introduce packet loss/issues. Enabling
ECN can reduce latency in some games with ECN-capable routers, and improve
throughput in the presence of packet loss. ECN is also recommended if using CoDel
algorithm to combat latency by dropping slowest packets on congested links.

Note: Known issue with profile logon to some EA games (likely router ECN-support
issue).

Checksum Offloading
Setting allows the network adapter to compute the checksum when transmitting
packets and verify the checksum when receiving packets to free up CPU, reduce
PCI traffic. 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).

Recommended: enabled

TCP Chimney Offload

TCP Chimney Offload allows for offloading the TCP processing work from the host
computer's CPU to the network adapter. This helps improve the processing of
network data on your computer without the need for additional programs or any loss
to manageability or security. Programs that are currently bound by network
processing overhead will generally scale better when used with TCP Chimney
Offload. 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 server environments.

Recommended: disabled (because of buggy implementations and issues with it,

also now considered deprecated by Microsoft now)

Notes: It does not work with NetDMA (NetTDMA is not supported under Windows 8
and newer)
See: Obsolete RFCs and Overview of TCP Timers

Large Send Offload (LSO)

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. The problem

8/19
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.

Recommended: disabled

TCP 1323 Timestamps

Timestamps are a RFC 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.

Recommended: disabled

Note: Under Windows Vista/7, under TCP 1323 Options we recommend leaving
only TCP "Window Scaling" enabled.

NetDMA (Windows Vista/7)

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. It must be
enabled/supported by your BIOS and your CPU must support Intel I/O Acceleration
Technology (I/OAT).

Recommended: use either TCP Chimney Offload or NetDMA, but not both.

NetDMA is not supported under Windows 8 and newer.

4. Advanced Settings
This section covers the "Advanced settings" tab of the program under current
Windows versions.

Internet Explorer Optimization

By default, the HTTP 1.1 specs in RFC 2616 recommend no more than 2
concurrent connections between a client and a web server. Similarly, HTTP 1.0
recommends up to 4 concurrent connections (HTTP 1.0 does not support persistent
connections, so it benefits from more concurrent connections). Traditionally, Internet
Explorer used the RFC recommendations, however, since IE8, Firefox 3, and
Chrome 4, most major browsers have departed from the recommendations in
search of faster web page loading speed by increasing the number of parallel
connections to web servers for both HTTP 1.0 and 1.1 to 6.

We recommend pushing this further to 8-10 concurrent connections per web server,
because of the complexity of web pages and the number of elements justify opening
multiple connections, especially with broadband internet connections. Note that
increasing the number of connections past 10 is not recommended, as some web

9/19
servers limit the number of concurrent connections per IP, and may throttle or drop
excessive connections, causing incomplete pages and worse user experience,
among other issues.

Host Resolution Priority

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 the priority of all four related processes compared to the hundreds of
other running processes, while keeping their order. It is important to note that the
"optimal" values we recommend are chosen in such a way as not to conflict with the
priorities of other processes, so, while other numbers may work, you should be
careful if departing from those values.

Refer to our Host Resolution Priority Tweak article for more details.

Retransmissions
The two values in this section control the way the system attempts to reestablish a
connection.

Max SYN Retransmissions - sets the number of attempts to reestablish a

connection using SYN packets.
Non Sack RTT Resiliency - controls RTT resiliency for non-SACK clients. This can
help slow clients/connections as it makes TCP/IP less aggressive in retransmitting
packets.

Retransmit Timeout (RTO) - Windows 8 and newer

Retransmit timeout (RTO) determines how many milliseconds of unacknowledged
data it takes before the connection is aborted. It can help reduce delays in
retransmitting data. The default timeout for Initial RTO of 3000ms (3 seconds) can
usually be lowered to ~2s for low-latency modern broadband connections, unless
you're in a remote location. Decreasing this number too aggressively on
connections with higher latency (satellite, remote locations) can increase premature
retransmissions. The RTO limit should not be triggered on a regular basis. The Min
RTO default/recommended value is 300ms.

See: RFC 6298

10/19
DNS Error Caching - Windows 7/Vista/2k/XP
This is designed to prevent caching of failed DNS lookups.

MaxNegativeCacheTtl: determines how long an entry recording a negative answer

to a query remains in the DNS cache (Windows XP/2003 specific)
NegativeCacheTime: determines how long an entry recording a negative answer to
a query remains in the DNS cache (Windows 2000/2008/Vista/Windows 7, replaces
MaxNegativeCacheTtl)

NetFailureCacheTime: determines for how long the DNS client stops sending
queries when it suspects that the network is down. During that time, the DNS client
returns a timeout response to all queries. If the value of this entry is 0, this is
disabled and DNS continues to send queries to an unresponsive network.

NegativeSOACacheTime: determines how long an entry recording a negative

answer to a query for an SOA (Start of Authority) record remains in the DNS cache.

Type/Quality of Service
This section deals with QoS policy and the Windows "QoS Packet Scheduler".

NonBestEffortLimit: The Windows QoS Packet Scheduler under Windows 7/8/8.1

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. Setting this to zero
prevents Windows from reserving 20% of bandwidth for such applications.

Do not use NLA: This undocumented setting is part of tcpip.sys that allows you to
set QoS DSCP values. Microsoft requires that Windows 7/8 systems have joined a
domain, and that the domain is visible to the particular network adapter in order to
be able to use local group policy to set DSCP values. Setting this to one removes
the limitation, allowing you to set DSCP without being part of a domain, and for all
network adapters. DSCP can be entered via local group policy using gpedit.msc

Gaming Tweak - Network Throttling Index, System Responsiveness

Network Throttling Index: Windows uses a throttling mechanism to restrict the
processing of non-multimedia network traffic. 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.

SystemResponsiveness: Multimedia applications use the "Multimedia Class

Scheduler" service (MMCSS) to ensure prioritized 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. The
Optimizer can reduce that reserved CPU for background processes from the default
of 20% to free up more CPU resources for games.

11/19
Note: 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.

Gaming Tweak - Disable Nagle's algorithm

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.

TcpAckFrequency: 1 for gaming and Wi-FI (disables nagling), small values over 2
for pure throughput.
TcpNoDelay: 1 for gaming (disables nagling), 0 to enable nagling
TcpDelAckTicks: 0 for gaming (disabled), 1-6 denotes 100-600ms. Setting to 1
reduces nagling effect (default is 2=200ms).

See also: Gaming Tweaks article.

Network Memory Allocation

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 settings in this section of the program
optimize the machine as a file server so it would allocate resources accordingly.

LargeSystemCache: we recommend setting this to 1 for LAN large file transfers to

allow the cache to expand beyond 8MB. However, some ATI videocards may have a
driver issue with corrupt cache and degraded application performance with this
enabled, so, for gaming, we recommend to leave it at zero/off.

Size: 1 minimizes used memory, 2 balances used memory, 3 is the optimal setting
for file sharing and network applications

Dynamic 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

12/19
settings to increase port availability and decrease the time to wait before reclaiming
unused ports.

MaxUserPort: denotes the maximum number of ports to use, recommended: 16384

to 65534 decimal as necessary.

TcpTimedWaitDelay: time to wait before reclaiming ports, in seconds. Default time

before reclaiming ports, we recommend using a value of 30 seconds. The default is
120-240 seconds, depending on your version of Windows.

5. Bandwidth Delay Product (BDP)

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 that affect
TCP/IP throughput.

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_anticipated_delay.

Even though the TCP Receive Window value can't be modified directly in modern
Windows variants, you can still adjust how aggressively the TCP auto-tuning
algorithm increases the RWIN value.

13/19
6. Latency

This section of the program helps test the latency of your 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.

7. Menus

14/19
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. It also
allows for resetting TCP/IP and Winsock to repair network connections that are
experiencing problems.

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 the "Optimal settings" recommendations of the
program, so if you're not sure what it does, leave it at the default of 300ms.
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. This is more relevant under Windows versions that support directly setting
the RWIN value.

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.

8. Apply Changes Screen

15/19
This screen offers preview of all changes before they are actually applied. The
lower-left also allows users to create a backup before applying any changes. If you
experience any issues with the TCP Optimizer, ticking the "Create Log" option in the
bottom-left corner allows for all commands to be logged along with the operating
system response to them. This log of all executed commands can greatly help in
debugging program issues and viewing output from the operating system. Creating
this log can help us troubleshoot any issues you experience with the program.
Backing up current settings for easy reversal is also recommended for new users.

Some changes may work without rebooting, however, the majority will only take
effect after rebooting your computer.

9. See Also
TCP Optimizer Download
TCP Optimizer Revision History
TCP Optimizer FAQ
TCP/IP Registry Tweaks articles

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.

User Reviews/Comments:
rate:

avg:

Changed my Windows 7 settings to your "optimal" v4.0 configuration, but the

Explorer didn't like the "TCP Window Auto Tuning = experimental". It stopped
responding when I tried to access the PCs own shares under Networks or when I
wanted to create new shares it also started to hang up. Setting the "TCP Window
Auto Tuning" to the default value could fix this.

THX a lot for this tool !

After many hours attempting to track down the source of DPC latency problems, this
fixed the issue pronto. Optimal settings worked like a charm. Thank you.

16/19
Thank you so much for this work.. I have been dealing with blipping audio on my
playback systems that disappeared after running TCP Optimizer.

You have made me a very happy man..

Best regards.

My outlook no longer works after running optimizer? any thoughts

Did you use the highest setting of the speed slider ? (It sets TCP Auto-Tuning to
"Experimental", try setting back to "Normal" if that is the case). If you need more
detailed help, please post in the forum.

I have 3 desktop (LAN) and 2 laptop (WIFI) computers at home. I am running

Windows 7 64-bit and my cable broadband is giving me 175 mbps.

I ran TCPOptimizer on all the machines. The desktops worked fine afterwards.
However the laptops could not connect to out email severs anymore. I changed the
TCP Window Auto-Tuning from Experimental to Normal on the laptops and was
able to connect to the email servers on one of the laptops - the other laptop still
wasn't able to connect. I reset the other laptop to Windows Default and it works fine
now.,

I am still interested in optimizing this laptop. Is the another setting you can point me
to to see if I can connect to the email servers after optimization?

Thanks so much!

blinker

A little correction to the above statements - one of my desktop machines did need to
be set back from Experimental to Normal as my CrashPlan backup system did not
work otherwise.

blinker

its works.. i can feel the change..

but my settings won't save..
every time i reboot, the settings rolls back to its prev state..
anyone knows how to fix this?

The TCP Optimizer reads many settings at start time, however, some may match
the Windows defaults, others may be Ethernet adapter-specific, and yet another set
of settings may not be able to be read to be correctly displayed. Those categories of
settings may not show as "optimized" even if the settings have in fact been applied.
I hope this helps

It look great.
But sadly wont save the settings after reboot, and the software ask for reboot after
changes.

Some fix, please?

17/19
The changes are applied, even if they don't show under "current" settings after
reboot.

This is due to the fact that some settings are network adapter-specific, others can't
be read/displayed by the OS (they may also be internet template-specific), and
lastly some may have the same current/default/optimal value.

Getting the following error when trying to set the congestion provider on Windows
Server 2019:
"Set supplemental command failed to update the specified template. The parameter
is incorrect."

Hello Guys, you have done an excellent job, solving the bandwidth optimization
difficult problem for a single file downloading. Thanks a lot.

Himmelherrgott - das Ding funzt ja richtig schnittig.

Hat alle Probleme gelöst

purtroppo con windows 10 mi dice error HKEY LOCAL MACHINE SYSTEM

...LOCAL PRIORITY ACCESS DINIED

For years my laptop was stuck with a 15mbps download speed regardless of actual
internet speed (ADSL and then FTTC at home, Tethering with phone at 100/100,
400/200 FTTH at work).
I tried *everything*.and I was going crazy and thought I'd replace the wifi module but
then someone suggested i tried this.

I just finished running this and now i'm finally doing 90mbps, the expected speed of
my FTTC

THANKS

I am glad it worked that well for you FBC, thanks for the feedback!
Pass it on, help others ;)

Despite my 100 Mbps internet connection, on my Windows 10 home PC I was

barely getting 40-50 Mbps in speedtest. I had tried various adapter settings,
different adapters, changing cables, bypassing a home switch etc., but nothing ever
really worked.

When I came across TCP Optimizer, I was a bit skeptical, as I am not a big fan of
"optimize" tools. However, having tried everything short of re-installing the OS
(which I was not even sure would make any difference), I decided to give it a go.
And I am very happy that I did.

With only a few clicks all settings got optimized (and the original settings backed
up), and I immediately reached 100 Mbps in speedtest, which just seemed
miraculous!

So a big thumbs up to the developers of this, and I will make sure to suggest it to
anyone having similar issues.

18/19
It is still broken for Windows Server 2019, as someone else already pointed out.
There is no workaround which makes the problem really annoying.
"Set supplemental command failed to update the specified template. The parameter
is incorrect." This happens because CUBIC is not a valid option for the netsh
command that the tool is trying to use to change this parameter (not sure why,
because there is no change from CUBIC to CUBIC).
PowerShell only has the latest implementation for this item, and it shows CUBIC for
all profiles on my system. Conversely cubic is missing as a valid option:
netsh int tcp set supplemental help
Usage: set supplemental [template=]automatic|datacenter|internet|compat|custom
[[minrto=]]
[[icw=]]
[[congestionprovider=]none|ctcp|dctcp|default]

Having said this, the tool still gives the same error, even when I change the setting
to something other than CUBIC. Indeed, very annoying. Too bad, because this is a
great tool.

This program seems to have saved many people's lives!

Before my PC was bad for games, after this Program, the quality went up A LOT in
connection with games!
And I see people saying that after installing this little program, which sort of solved
their lives 100%,
then I just remember my friend installing it and asking me: "What happened to my
Net, what did you do with my Net?, It's much better"
kkkk/lol (HAHA)

👍
I loved this quality boost through this porgram, and I recommend it to People! :) 🙂
Esse Programa parece ter salvo a vida de muita gente!
Antes meu PC ficava ruim pra jogos, depois desse Programa, a qualidade subia
MUITO na conexão com jogos!
E eu vendo vendo pessoas falando que depois de instalar esse programinha, que
presumivelmente tipo 100% a Vida deles,
aí eu só lembro meu amigo instalando e me Perguntando: "O que aconeteceu com
minha Net, oq ue vc fez com minha Net?, Tá muito melhor"
kkkk (HAHA)

Eu amei esse aumento de qualidade por esse porgrama, e recomendo ele para as
pessoas! :)

Related Articles:

19/19