Shortcuts
|
Windows 2k/XP Registry Tweaks2001-03-31 (updated: 2015-04-06) by PhilipTags: AFD, Registry, tweak, TCP/IP, TcpMaxDupAcks, SackOpts, TTL, TCP Window Windows 2000 and XP are built on NT technology and both are generally better optimized for networking than Windows 9x and even NT4. Regardless, both XP and 2000 are still configured with respect to Ethernet rather than high-speed Internet connections, where latency plays a major role in throughput. Here, you will find specific information on how to optimize the Windows 2000/XP Registry for Cable Modems, DSL, or any similar type of broadband Internet connection. Customizing the Windows Registry assumes some proficiency in tuning Windows configuration files. If you don't feel comfortable editing it, please use our TCP Optimizer program, or the Windows 2000/XP registry patches from the Downloads section of the site. both those options will add all the parameters and set all the optimal values in the Registry automatically for you. If you'd rather make the changes yourself, or prefer to experiment with different values to fine-tune your connection, follow the directions for editing the Registry below. Editing the Windows 2000/XP RegistryTo edit the Registry, you need to use an editor, such as Regedit. As with previous Windows versions, it can be accessed from the Start Menu ( START > Run > type "Regedit" ). Note that most of the values recommended on these pages are not present in the Registry by default and you might have to add them manually. Also, for most of the tweaks to take effect you must Reboot. It is strongly recommended that you backup your Registry before editing. The easiest way to backup your Registry is from within the Registry Editor, just choose "Export Registry File" from the pull-down menu. Recommended settings for Windows 2000 / XPWindows 2000 & XP, unlike NT supports large windows as described in RFC1323 ( the 'RcvWindow' has a maximum value of 2**30 rather than 64K), and includes some other improvements over its predecessors you can use to speed up any TCP/IP transfers. The best settings are listed in red, the descriptions and other options are added to provide you with better understanding and enable you to customize your settings. All the following entries, unless otherwise noted should be placed in the Windows 2000/XP Registry under the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters TCPWindowSizeThe value of the TCP Window in the Windows 2k/XP Registry is probably the single most importan setting that will offer the most benefit to improving your internet connection. The recommended value (in red) will optimize TCP for any high speed broadband internet connection. It will work well for most cases, however, if you'd like to use a custom value make sure to follow these guidelines: For best results, the TCPWindow should be a multiple of MSS (Maximum Segment Size). MSS is generally MTU - 40 (20 byte TCP and 20 byte IP headers), where MTU (Maximum Transmission Unit) is the largest packet size that can be transmitted. MTU is usually 1500 bytes (1492 for PPPoE connections). To determine the exact MTU value of your ISP, check out the Advanced Registry Editing section of our site or use the TCP Optimizer. There are three places in the Windows Registry where you can add the TCP Window parameter. HKLM/SYSTEM\CurrentControlSet\Services\Tcpip\Parameters HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters TcpWindowSize can also exist under TcpipParametersInterface - if added at this location, it overrides the global setting for this particular NIC. Note: For best results RWIN has to be a multiple of MSS lower than 65535 times a scale factor that's a power of 2, i.e. 44 x 1460 = 64240 x 2^2 = 256960. If you choose to use a RWIN lower than 65535, you can simply make it multiple of MSS and turn scaling off (Tcp1323Opts=0).
Tcp1323OptsTcp1323Opts is a necessary setting in order to enable Large TCP Window support as described in RFC 1323. Without this parameter, the TCP Window is limited to 64K. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters DefaultTTLDefaultTTL determines the time in seconds and the number of hops a packet lives (every hop reduces it by at least 1). While it does not directly affect speed, a larger value increases the amount of time it takes for a packet to be considered lost, discarded and retransmitted. A value that's too small can cause packets to be unable to reach distant servers at all. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters EnablePMTUDiscoveryWhen set to 1 (True), TCP attempts to discover MTU automatically over the path to a remote host. Setting this parameter to 0 causes MTU to default to 576 which reduces overall performance over high speed connections. Note: setting is different than our Windows 9x recommendation HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters EnablePMTUBHDetectSetting this parameter to 1 (True) enables "black hole" routers to be detected, however it also increases the maximum number of retransmissions for a given segment. In most cases you'd want to keep BHDetect at 0 (False). HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters SackOptsThis 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. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters TcpMaxDupAcksThis parameter determines the number of duplicate ACKs 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. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Additional TCP/IP Related ParametersThe additional TCP related parameters are not necessary in most cases, and you shouldn't expect any drastic improvements, however we added them for those of you who like experimenting. You might be able to gain that last bit of performance, or customize your TCP/IP behavior even more with those. Keep in mind you should familiarize yourself with what the parameters mean and how they affect your connection before changing their values MTUSetting MTU overrides the default MTU for the network interface it is added to. Note that if EnablePMTUDiscovery is set to 1, TCP will use the smaller value of this local MTU and the "Discovered" MTU of the underlying network connection. If you'd rather use only the MTU value specified here, you'd have to disable PMTUDiscovery, which would prevent your system from detecting the network MTU. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces Note: For Windows XP PPPoE, there is an additional location for MTU that might need to be adjusted (to 1480, or up to 1492 as per the PPPoE specs), depending on the PPPoE software you use. Check the following location in the Registry: AFD ParametersAfd.sys is the kernel-mode driver used to support Windows Sockets applications. DefaultReceiveWindowThe number of receive bytes that AFD buffers on a connection before imposing flow control. For some applications, a larger value here may give a sligtly better performance at the expense of increased resource utilization. Applications can modify this value on a per-socket basis. Registry Location: DefaultSendWindowSame as the above setting for the send side of connections. Registry Location: Datagram SizeMS Windows supports a fast I/O path which is utilized when sending "small" datagrams (packets). The default setting for what is considered "small" datagram is 1024 bytes; increasing this value to match your network MTU (normally 1500) can significantly improve network performance. To adjust this parameter: Note: setting not in the current version of the TCP Optimizer. FastCopyReceiveThresholdWhen an application posts a receive with a buffer that is smaller than the current packet being buffered by Winsock, AFD can either make an additional copy of the packet and then copy data to the application buffers directly (two-stage copy because application buffers cannot be accessed directly under the lock), or it can lock and map application buffers and copy data once. This value represents a compromise between extra code execution for data copying, and extra code execution in the I/O subsystem and memory manager. To adjust this parameter: HKLM\SYSTEM\CurrentControlSet\Services\AFD\Parameters IgnorePushBitOnReceiveSetting this parameter to 1 causes Afd.sys to treat all incoming packets as though the push bit was set. We recommend leaving this at the default of 0 (disabled). Registry Location: References: Technet Web PatchAccording to the HTTP specs, only limited number of simultaneous connections are allowed, while loading pages. To increase that number in Internet Explorer, you can add the following entries to the Registry (they are not present by default). For Firefox, refer to our browser tweaks article. HKEY_USERS.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Internet Settings HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings Notes: Keep in mind that increasing those values exceeds the HTTP specs. Increasing them much over 10 may cause problems with some websites. While these entries might improve web page loading considerably, they tend to strain webservers more and have no effect on throughput. Alternatively, you can download a patch (sguide_webtweak_2k) that will add these entries for you automatically from the Downloads section of our site. For additional tweaks and information, check our other related articles:
User Reviews/Comments:
rate:
avg:
by
anonymous - 2006-07-14 00:13
As a web server admin, I advise everyone to NOT apply the 'Windows 2000 Web Patch' or any other similar HTTP connection tweaks. They cause serious load problems on web servers - normally a client takes 2 connection slots, so a 200 client server can handle 100 simultaneous users no problem. However when this "tweak" is applied, 100 users becomes just 10 users! This is a really nasty tweak that essentially causes a denial of service attack against web servers. Please do not use it. With properly configured RWIN and pipelining, you will get better performance out of 2 single connections since you won't have the overhead of connection setup + teardown.
by
Philip - 2006-07-24 12:27
Applying the web patch is not a DDoS in any form. Yes, it causes the user to make more requests to the webserver at once, but at the same time it reduces the time this user takes to download web pages.
So, by using the same theoretical simple comparison, the 10 users will download those pages 10 times faster, freeing the line for others. As a web server admin myself, I'd recommend reducing the "KeepAliveTimeout" to 6-7 seconds (from the default 15 seconds with Apache) to reduce any potential load from having a large number of open connections.
by
anonymous - 2006-08-08 14:45
This is a fallicy: opening more connections will *not* get you higher performance; if anything, you will get worse performance; the multiple connections can havoc with TCP's congestion control measures.
The highest TCP performance is seen using a single TCP connection. http://www.google.com/url?sa=t&ct=res&cd=4&url=http%3A%2F%2Fwww.sigcomm.org%2Fsigcomm97%2Fpapers%2Fp102.pdf&ei=dNvYRMK3LMa4avS4pPwH&sig2=csgWnYb9mZpXdC3Y0PVunw
by
Philip - 2006-08-08 16:45
Still we've tested the "MaxConnectionsPerServer" settings extensively in real world situations from the client side of view. Increasing the number of connections (to a reasonable number) allows for more requests to be made simultaneously, before waiting for previous requests to complete. When you also consider going through routers that handle requests from many clients, and the connection latency, it results in a noticeably more responsive browsing. TCP Congestion Control should not be an issue with web pages (serving multiple *small* files).
by
anonymous - 2006-08-21 21:15
by
Philip - 2006-08-23 08:34
Tweaking your connection is very different than uncapping (illegally changing your CPE to get bandwidth not allocated to you).
By tweaking, you are optimizing your end of the connection (your computer), you're not taking anyone's bandwidth. Tweaking just helps you utilize your allocated bandwidth by your ISP to its full potential. If one uses the default Windows settings with broadband, transfers usually burst until they fill the TCP Window buffer, then servers stop and wait for acknowledgements that the data has been received to send more... It is simply not handled well, we increase those buffers to allow filling the full bandwidth. Optimizing is recommended by many providers, our site, tweaks, patches and programs have been recommended by field techs and mass media for the past 7 years. Our goal is simply to help end users utilize their broadband connection to its full potential.
by
a white rabbit - 2006-08-29 04:52
..to anonymous, ....
..my ISP promises 100mbs, i get dl/uls that start at a reasonable 150+ kBs but drop rapidly to 15-20 or lower, Taskmanager shows me to be using at best 0.9% of available, my dl/ul rate gets slaughtered when a local cybercafe comes on line at school leaving time, despite repeated requests to the ISP nothing has been changed... ..the computer used to do T1+ very nicely over copper cable in France with 128K RAM, its now 2*256 and souped up as much as HP can manage, i've done all i can to improve my situation nicely, and at my cost... ..i reckon i'm due the extra band-width, enlarging the TCP-IP seems the next step, and a legit one that applies to all false advertising ISPs of which there are many
by
Maisriemler - 2006-09-07 13:29
Excelent Article.
I downloaded TCPOptimizer and wanted to print http://www.speedguide.net/tcpoptimizer.php IE cuts off the right 2 inches, and Firefox just crashes. Is ther an pdf document to print it? Ferdinand Maisriemler
by
Matthias - 2006-09-09 20:30
by
Maisriemler - 2006-09-13 12:55
by
Sava700 - 2007-01-21 16:53
by
WKjun - 2007-01-30 10:10
by
Philip - 2007-01-30 16:14
If you meant the web patch: 99% of web pages consist of multiple files, I'd say an average number is 20-30 total files, including small images, stylesheets, javascript, etc. However, it's been my experience that if you increase the number of concurrent requests over 8-10, servers may start dropping some of your connections.
by
anonymous - 2007-02-14 01:57
really, there shouldn't be any argument as to whether or not you should apply the web patch. i've gone through network admin and programming jobs and from my experience it's really a case to case basis thing. let me explain.
let's first assume that your internet connection to the web server in question has a global bandwidth cap applied but no per-connection bandwidth cap. let's assume it's 100kb/s and you're not using your net connection for anything else. you go visit a web page that requires you to download, say, 20 files and you have your registry settings at the default of 2. what happens here is that you have 2 connections running at the same time sharing 100kb/s so that's 50kb/s connection. what you don't realize is that each of your 2 connections eat up ram and other resources you aren't aware of, both on your pc, and on the server. next, you bump up your registry settings to allow 20 connections. now when visiting the site, you get 20 connections sharing your bandwidth for around 10kb/s each. so you don't get any real advantage here as it will load at practically the same speed and you just end up eating 10x as much resources on both your pc and the webserver you're downloading those files from. so in this case, allowing more connections doesn't really work in this case. however, in cases where the webserver you're visiting, or even your own net connection, has a per-connection bandwidth cap, the case is different. say the same situation, except you have a 5kb/s per-connection cap (this is low, but let's assume this just for the sake of argument). using only 2 connections at the same time, you only use a total of 10kb/sec. however, having 20 connections at the same time allows you to make full use of your 100kb/sec, allowing you to load the page 10x faster at the expense of eating up resources on your pc and on the webserver. now, if everybody actually did bump their registry settings to use up 10x more connections than normal, the effect would indeed be a ddos attack, not because of the combined download speeds, but because that effectively increased the amount of resources required of the server by 10x, and that isn't a small amount. so as a matter of courtesy, one is adviced not to use the web patch. after all, the http specs didn't put a limit the number of connections for nothing. that said, any good network admin should know how to limit the number of connections per client properly.
by
Philip - 2007-02-14 09:34
There are a few other factors to consider as well:
Assume that same page with 20 files and 200ms latency between you and the webserver. Using the default 2 connections, you will have to add 10 times 200ms (2 seconds) to your waiting time for request to get to the web server and back. You may even have to double it considering ACKnowledgement packets. With 10 connections, you will have to wait only 400ms (0.4 seconds), or 5 times less. Also, residential broadband is oversubscribed, usually 20 times. In other words, very often the bottleneck of the connection is not your cap, rather your ISPs backbones, or the server's backbones, or the slowest connection in between. Making more requests at the same time allows for the files to get cached on a router near you, so you can get closer to your capped speed, as opposed to waiting for the slowest link for each file separately, with interruptions for each packet/acknowledgement to travel through the network. Today's computers are capable of handling tens of thousands connections at a time without a problem. The local resourse utilization difference between 2 and 10 open connections is negligible compared to the network performance increase. It is similar to the benefit P2P programs have from opening hundreds of connections at the same time, versus downloading from 2 peers. Just test and see what works for you. It is a very valid tweak.
by
Rusty - 2007-02-15 22:47
Would this be a cause for intermittent disconnects? I use cable and have a SB5101 modem.
It seems that something is blocking up an disconnecting my programs from the internet (although the modem and ISP software remains connected). Once disconnected whatever it is "unblocks" itself and reconnects? Any thoughts?
by
angus49 - 2007-03-04 10:42
by
Pakrat - 2007-03-20 11:51
I constantly have multiple IE windows open. If I'm on a machine that does not have the connections patch applied, then when I go to download more than one file at a time (no matter what the size), IE will not continue on that next window (hangs).
I classify myself as a super-power-user. This patch may not be necessary for the average user. Actually, the average user wouldn't even utilize the patch if it was installed. So, it doesn't matter.
by
Thorsten Albrecht - 2007-04-17 10:03
For tweaking the global TcpWindowSize in Windows 2000, you can use "TcpWindowSize" instead of "GlobalMaxTcpWindowSize" (see http://support.microsoft.com/kb/263088/en-us). It's enough.
Thorsten
by
PonchoWest - 2007-06-05 13:05
And this is the point that ‘anonymous’ is missing, not everyone is running a big office size network. Most of us use a router and 2-4 computers, my self I only use 10 computers and I’m 90% user on the computers, the wife and kids use things like the web phone and some Xbox gaming.
Our ISP is Clearwire which is a wireless internet and I pay for 1.5mbps but I know the most I should get is around 1000kbps – 1200kbps and that is not the case, not even close. I get from 16kbps yeah you read that right and on good days I get upwards of 500kbps and the Clearwire tech guy said that I should be happy to get that. Well if he calls on me to do a job for him for 100 hours of work he should he happy if I show up for 50 hours and I’ll still bill him for the 100 hours. Anyway I just ran across this site today and I’m going to run the Tweak and or edit the reg my self and see what happens. The thing is I get slow download speeds on all my computers from the Win98-WinXP and even my new Vista Dell but then it’s a Dell…LOL! I have tweaked the LinkSys WRT54G router and no help there after this download tweak the next thing is to see if I have a bad Clearwire modem, I guess. How can I tell if and what the CPE or the cap is on my Clearwire service? OH and the copy past worked fine for me. Poncho West heritage-media.com
by
Stefan - 2007-06-05 17:45
Just stumbled upon this page while looking for something else. Discussion grabbed my attention, because it's one of those things that keep coming back.
Both viewpoints have valid arguments, but to the end I feel that the one of anonymous is the most correct one. Without going all over it again: there's this one and only reason why souping up your connection is a no-no: if all people start doing it, the net would become unsurfable. It's true that 99% of the surfers never would undertake such actions and thus the effect of a few greedy connections isn't that breathtaking. But imagine when 50% starts doing it... And I don't use the word greedy here for no reason: it's a loathable practice to take more than your average Joe, just because you know how. That applies to many things in the world, so why should this be different? In the end it comes down to the same thing as a highway speed limit: you CAN drive at 250 km/h, but I'm sure most people would agree you'd rather not. One last remark: on the servers I happen to admin: such connections get cut short after breaking the greedy limit a bit too often. Iptables has all the tools onboard to do that. How it works is way too technical for explaining here, but I found all I needed on the net. Just to get you going: those lightning speed downloads crumble to almost stand-still after the first few seconds. This happens when the firewall decides that one pc is using suspicious amounts of connections. Kinda like countering DDOS-attacks, yes. I ever hosted a network on a fair which allowed downloading and surfing just like at home. Only what we didn't want were guys hogging up the resources because of film downloads. And boy was it amusing to see those faces when their downloads began to take forever after the first megabyte. Lol. Another issue, but the cure is closely related to what I mentioned before. Btw, perhaps the type of person doing it is also closely related? ;)
by
unix guy - 2007-06-07 14:20
by
cobes - 2007-09-12 23:08
I just have a comment about potentially hogging up server resources by utilizing multiple connections. It seems logical (to me anyway) that a server would want to deliver the requested file(s) quickly and be done with it so it could free up available system resources to be ready for the next request. So based on this assumption, one would think that a server would welcome a request that could process the file delivery quickly... Obviously, if made within reason.
With more users signing up for cable and DSL internet services, webhosts are going to need to continuously upgrade their equipment to be able to handle the ever increasing demand for file delivery, which means it is to their advantage to be able to deliver these file requests quickly as well. I also agree to a point that it's somewhat unfair for someone to hog a webhosts system resources to the point that nobody else can get a reasonable connection as well. Just as someone who buys a first class airfare ticket will get more room, better seats, better food, etc., someone who can afford broadband service should also be entitled to better service than someone using a dial-up connection. Also, if good information regarding broadband optimization is available to those advanced users who seek it, why not fully utilize those techniques that are available to you? Like one guy said, what good is a download speed of 1.5Mbs, when you can ONLY get 500kbs? That's a nearly 66% loss of "available" download speed left on the table. Perhaps if he had optimized his internet connection, he could've bumped that up to a speed of around 1.3Mbs. I'm running Verizon DSL @3.0 Mbs and I usually run at around 2.8Mbs when I test my speed. (and I'm still not satisfied. LOL) Kidding. From what I understand, if you can get around 90% of your rated speed, that's very good and it's about the best you can expect. What I am trying to improve upon is the initial connection to any website...that annoying 1-5 second delay (latency, perhaps). So, I will continue until I see an improvement in that area. Happy Optimizing! cobes...
by
starsky - 2007-09-27 17:28
by
Saabdiver - 2007-11-09 06:20
|