News Glossary of Terms FAQs Polls Cool Links SpeedGuide Teams SG Premium Services SG Gear Store
Registry Tweaks Broadband Tools Downloads/Patches Broadband Hardware SG Ports Database Security Default Passwords User Stories
Broadband Routers Wireless Firewalls / VPNs Software Hardware User Reviews
Broadband Security Editorials General User Articles Quick Reference
Broadband Forums General Discussions
Advertising Awards Link to us Server Statistics Helping SG About
The Broadband Guide
SG
search advanced
 Username:
 Password:
Register
 forgot your password?

Windows 2k/XP Registry Tweaks

2001.03.31 11:00 by Philip
Tags: 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 Registry

To 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 / XP

Windows 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

TCPWindowSize

The 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
GlobalMaxTcpWindowSize="256960"
(DWORD, number of bytes) Valid range is from MSS to 2^30. Add the value as a decimal. 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)

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
TcpWindowSize="256960"
(DWORD, number of bytes) Valid range is from MSS to 2^30. Add the value as a decimal.
Note (10/20/00): Seems MS has found another bug in Windows 2000, the TCPWindowSize should be configured with the global setting (GlobalMaxTcpWindowsSize) rather than this one - Q263088

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

 

Tcp1323Opts

Tcp1323Opts 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
Tcp1323Opts="1"
(DWORD, recommended setting is 1. The possible settings are 0 - Disable RFC 1323 options, 1 - Window scaling but no Timestamp options, 3 - Window scaling and Time stamp options.)

Note: Tcp1323Opts="3" might help in some cases where there is increased packet loss, however generally you'll achieve better throughput with Tcp1323Opts="1", since Timestamps add 12 bytes to the header of each packet.

  

DefaultTTL

DefaultTTL 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
DefaultTTL="64"
(DWORD, recommended setting is 64. Other settings that are widely used are 128 and 32)

 

EnablePMTUDiscovery

When 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
EnablePMTUDiscovery="1"
(DWORD - boolean, valid settings are 0-->False and 1-->True. Many connections perform better with this entry at 1, however, if you prefer to set your upstream to send fixed 1500 packets, you might want to use 0 instead). When set at 1, establishing connections and initial transfer speed might slow down a bit, however you will get better throughput if somewhere in the path large packets need to be fragmented.

 

EnablePMTUBHDetect

Setting 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
EnablePMTUBHDetect="0"
(DWORD - boolean, valid settings are 0 = False and 1 = True. Recommended setting is 0)

 

SackOpts

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.

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
SackOpts="1"
(DWORD - boolean, recommended setting is 1. Possible settings are 0 = No Sack options, or 1 = Sack Option enabled).

 

TcpMaxDupAcks

This 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
TcpMaxDupAcks="2"
(DWORD - range 1-3, recommended setting is 2).

  

Additional TCP/IP Related Parameters

The 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

MTU
Setting 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
MTU="1500"
(DWORD, valid range is from 68 to MTU of network).

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:
HKLM\SYSTEM\CurrentControlSet\Services\NdisWan\Parameters\Protocols\0
ProtocolMTU="1480"
 

 

AFD Parameters

Afd.sys is the kernel-mode driver used to support Windows Sockets applications.

DefaultReceiveWindow
The 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:
HKLM\SYSTEM\CurrentControlSet\Services\Afd\Parameters
DefaultReceiveWindow
  (DWORD, not present by default. Recommended: leave blank as is, since this value limits the TCP/IP  TcpWindowSize RWIN value)

DefaultSendWindow
Same as the above setting for the send side of connections. 

Registry Location:
HKLM\SYSTEM\CurrentControlSet\Services\Afd\Parameters
DefaultSendWindow
  (DWORD, not present by default. Recommended: leave blank as is. Alternatively, you can enter a value up to the TCP/IP TcpWindowSize RWIN setting)

Datagram Size
MS 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:
HKLM\SYSTEM\CurrentControlSet\Services\AFD\Parameters
FastSendDatagramThreshold=1500  (DWORD value, 1024 by default when not present, recommended: 1500 decimal)

Note: setting not in the current version of the TCP Optimizer.

FastCopyReceiveThreshold
When 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
FastCopyReceiveThreshold=1500
(DWORD, 1024 by default when not present, recommended: 1500 decimal)

 

IgnorePushBitOnReceive
Setting 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:
HKLM\SYSTEM\CurrentControlSet\Services\AFD\Parameters
IgnorePushBitOnReceive
  (DWORD boolean, 0 by default when not present, recommended: don't set)

References: Technet

 

Web Patch

According 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
"MaxConnectionsPerServer"=dword:00000010
"MaxConnectionsPer1_0Server"=dword:00000010

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
"MaxConnectionsPerServer"=dword:00000010
"MaxConnectionsPer1_0Server"=dword:00000010

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:
Windows 2k/XP - More Tweaks
Advanced Tweaking
Host Resolution Priority Tweak
Browser Tweaks
LAN Tweaking
Windows Vista / 2008 Tweaks

  

  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
I just love watching you guys duke it out! Sure, you can eat more food if you grab it off the other guy's plate. The tweaks are kinda like cutting in line in the cafeteria. But the guy cutting in line has done his homework. Risk and reward? You tell me. ( And I'm sure you will.)
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
I need to thank those who have contributed to building the informational guide of this website; a newbie to much of this gives me renewed awe at the vast amount of intellectual effort vested in the creation of the computer system.

Thanks!

Best Regards,



Matthew W. Johnson, Analyst
by Maisriemler - 2006.09.13 12:55
Once again, a really excellent article that helped me a lot. In meantime I also solved my printing problems using the free pdf Creator.

Thanks!
Ferdinand Maisriemler
by Sava700 - 2007.01.21 16:53
This tweak really does make a difference.. if its not making you one you have something else wrong!
by WKjun - 2007.01.30 10:10
One single connection might do a better job for everyone, but if you want to download more than two files at once, then you should apply this patch.
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
I Know your post is quite old now and maybe you've had answer to your question, but incase not, here is your solution. Simply highlight the article and do a copy and paste into notepad. Worked grat for me.
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
FYI, network tuning isn't just for people that want to surf faster, in fact it is not even for that. It is for data transfers. The people that think that a 100Mbps connection should allow or a 100 Mb file to be transfered in 1 second.
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
why do u need new connection for new request. is that not just the difference between persistant and non persistant connections?
by Saabdiver - 2007.11.09 06:20
Try generating s Print Preview and then printing from there.
 1 | 2 Next page (2) comment print discuss top

exec. time: 0.01442 s
Copyright © 1998-2014 Speed Guide, Inc. All rights reserved.
Terms of Use | Privacy Policy