Speed Tweak Myths and Legends If you are confused about the number of claims made by SPEED IMPROVEMENT programs and websites and registry patches, looking at this tweak matrix will help. The page was recently added to the Tweaks section. Check out the tweak matrix to see, for your version of Windows, which of the commonly mentioned registry changes actually make a difference. Life is a lot simpler for users of non-windows operating systems!
|
 | Anon |  Re: Speed Tweak Myths and Legends
I was able to easily test my tweaks with iSpeed and a consistent fast FTP server, and reached pretty much the same conclusion for Win 98SE. So no excuse for not showing what has led you to the posted conclusions, other than opinion and/or belief.
Show me the data!! | |
|  |  GPrestonHows Ya Durrin?
join:2000-04-15
Dallas, TX |  Re: Speed Tweak Myths and Legends
I have therefore edited out the other tweaks that are included in the typical speedguide.net inf files. | |
| |  justinAustralian
join:1999-05-28
New York, NY
kudos:7
IPv6
Business Connectiv..
Console/Handheld g..
Console Tech
Home/Office setup ..
| You merely need explore the microsoft knowledge base to see the statements on what is default or not, and what is ignored. In the tweak matrix, some of the relevant articles are named.. (MS keeps changing their links around so a link would get old fast, but the article numbers stay the same).
The trouble with MEASURING tweaks is the sheer number of trials you have to do, to prove an improvement. And windows makes you reboot between changes! argh!
Most people test once, tweak, then test again. If it improves by 10%, they think eureka, whereas, in any speed test things can be plus/minus 20% trial to trial - especially for cable modem users where most of these tweaks originated from.. to really test, you need TWO or more machines, and need to test at the SAME time to the SAME server.. and generate speed plots of the data coming in. Do this several times. Then pick another server further away, or of a different OS, to test whether the same improvements show with that.
Or you build a TCP simulator, complete with simulated delay and simulated packet loss, and test in a lab.
Any other tests are not worth the web page they are written on since by the time you reboot, the state of the net has changed.. and can continue to shift in one direction, faster, or slower, for hours (its normal daily cycle).
Testing RWIN values is much easier (because RWIN below optimal size for the site you are on is like a speed volume control). It fits theory exactly.. RWIN sizes beyond theory optimal return to the land of noise though. | |
|
| Anon | Here's a question...why waste time with some large matrix of information that basically just says what so many other articles have said in the past. No reason to have a link to another page. Just say the receive window is the only tweak that makes a positive difference. If there were some numbers and more verbose explanations then sure it would be worthwhile. But with so many n/a and so few greens there's no point. | |
| | Anon | I disagree with the statement about the SAck option (RFC 2018). Especially with a large receive window, SAck becomes increasingly important - without SAck, a single lost packet can cause an entire receive window's length of data to be dropped.
For a real-life example: The Internet in Germany is basically divided into two portions: Commercial Internet and the "German Science Network", to which all universities are connected. The gateway between these two portions is typically overloaded, with packet loss of 20% or greater.
When trying to _upload_ a file through DSL (Commercial Internet) to a university account with a large window, the ftp transfer stalled after a few hundred kbytes and would sometimes completely get stuck. Enabling the SAck option allowed uploading steadily with only minor delays, at ~75% of the upstream bandwidth! Toggling the SAck option a few times confirmed that it is indeed this option that makes the difference (and not changed networking conditions)...
So I personally recommend to turn ON the SAck option when you configure a large TCP window size! | |
|
| |
|
|
