XP SP2 hows that work??

farmerbob · Post by **farmerbob** » Tue Aug 31, 2004 11:34 pm

I have wireless highspeed internet access from CMINET.NET, their advertised speed is 768kbps download /768kbps upload. I have an XP machine. I have installed all tweaks from speedguide.net prior to installing SP2, my tests from speakeasy were very typically 725/640, after installing SP2 and reinstalling all tweaks and checking settings my test results are now 675/650. Hows that happen?

TCP properties for IP = xxxxxxxxxx()
Browser/OS = Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; YComp 5.0.0.0; SV1; .NET CLR 1.0.3705)
Notes: Read the Analyzer FAQ if the above is not your IP address.

TCP options string = 020405b40103030201010402
MTU = 1500
MTU is fully optimized for broadband.
MSS = 1460
Maximum useful data in each packet = 1460, which equals MSS.

Default Receive Window (RWIN) = 256000
RWIN Scaling (RFC1323) = 2 bits (scale factor of 4)
Unscaled Receive Window = 64000

For optimum performance, consider changing RWIN to a multiple of MSS.
Other values for RWIN that might work well with your current MTU/MSS:
513920 (MSS x 44 * scale factor of 8)
256960 (MSS x 44 * scale factor of 4)
128480 (MSS x 44 * scale factor of 2)
64240 (MSS x 44)
bandwidth * delay product (Note this is not a speed test):

Your RcvWindow limits you to: 10240 kbps (1280 KBytes/s) @ 200ms
Your RcvWindow limits you to: 4096 kbps (512 KBytes/s) @ 500ms
MTU Discovery (RFC1191) = ON
Time to live left = 55 hops

TTL value is ok.
Timestamps (RFC1323) = OFF
Selective Acknowledgements (RFC2018) = ON
IP type of service field (RFC1349) = 01011100

Precedence (priority) = 100 (flash override)
Delay = 1 (low delay)
Throughput = 1 (high throughput)
Reliability = 0 (normal reliability)
Cost = 1 (low cost)

mccoffee · Post by **mccoffee** » Wed Sep 01, 2004 12:31 am

Did you disable the firewall for xp sp2?? I would try that

farmerbob · Post by **farmerbob** » Wed Sep 01, 2004 9:47 am

I read through some of the previous topics on SP2 and did all of the things you had told other people to try including disabling the windows firewall.

mnosteele52 · Post by **mnosteele52** » Wed Sep 01, 2004 9:56 am

farmerbob use the following settings in CableNut:

DefaultReceiveWindow = 98304
DefaultSendWindow = 98304
DisableAddressSharing = 1
InitialLargeBufferCount = 200
InitialMediumBufferCount = 480
InitialSmallBufferCount = 640
LargeBufferSize = 819200
MaxFastTransmit = 64000
MediumBufferSize = 150400
PriorityBoost = 0
SmallBufferSize = 12800
TransmitWorker = 32
FastSendDatagramThreshold = 1024
EnableFastRouteLookup = 1
EnablePMTUDiscovery = 1
IgnorePushBitsOnReceive = 0
GlobalMaxTcpWindowSize = 32120
MaxFreeTcbs = 8000
MaxHashTableSize = 16384
MaxNormLookupMemory = 5000000
SackOpts = 1
SynAttackProtect = 1
Tcp1323Opts = 0
TcpLogLevel = 1
TcpMaxDupAcks = 2
TcpMaxHalfOpen = 100
TcpMaxHalfRetried = 80
TcpRecvSegmentSize = 1460
TcpSendSegmentSize = 1460
TcpTimedWaitDelay = 30
TcpUseRFC1122UrgentPointer = 0
TcpWindowSize = 32120
MaxConnectionsPer1_0Server = 10
MaxConnectionsPerServer = 8
DefaultTTL = 128
DisableUserTOSSetting = 0
TcpMaxDataRetransmissions = 6
DefaultTOSValue = 240

VERY IMPORTANT TO DO THE FOLLOWING

1. Under your LAN connection - properties - general tab, uninstall all the protocols there that you do not need.

2. Open IE and select tools - internet options - connections - LAN settings, make sure NOTHING there is checked.

3. ALWAYS connect your modem via ethernet (NIC) and make sure you have the latest drivers for your NIC from the manufacturer and set your duplex mode to "auto". If you are using a router make sure you have the latest firmware. DO NOT CONNECT YOUR MODEM VIA USB!!

4. Clear your temporary internet files.

5. Power cycle your modem, unplug it for at least 15 seconds.

6. Download, update and scan with SpyBot S&D EXACTLY as I explain HERE & Ad-Aware EXACTLY as I explain HERE to remove any spyware then install and update SpywareBlaster to stay spyware FREE. YOU MUST USE BOTH AD AWARE & SPYBOT TO ENSURE YOU ARE SPYWARE FREE SINCE ONE FINDS WHAT THE OTHER MISSES.

7. Make sure you do the faster web page tweak in my Help & Tips link.

8. If you have Zone Alarm as a firewall uninstall it and search your pc for the left over files.

9. Install Sygate Firewall they have a FREE and Pro version.

10. Scan for viruses with your antivirus app, if you do not have one get one IMMEDIATELY, I recommend using AVG 6.0 it is an excellent FREE AV app. Make sure you set it up EXACTLY as I explain HERE.

11. Make sure you have ALL of the latest Windows Updates.

farmerbob · Post by **farmerbob** » Thu Sep 02, 2004 12:31 am

hey guys, thanks for all your help but I guess the speeds I'm getting are about the best it's going to get. I don't know why it changed but it did it's not a noticable change except for an actual speed test

farmerbob · Post by **farmerbob** » Wed Sep 15, 2004 9:46 pm

hey all, I think I have gotten my original speed back (725/ 650) with the tweaks listed below thanks for your interest and help

SpeedGuide.net TCP/IP Analyzer

TCP properties for IP = xx.xxx.xxx.xx ()
Browser/OS = Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; YComp 5.0.0.0; SV1; .NET CLR 1.0.3705)
Notes: Read the Analyzer FAQ if the above is not your IP address.

TCP options string = 020405b40103030301010402
MTU = 1500
MTU is fully optimized for broadband.
MSS = 1460
Maximum useful data in each packet = 1460, which equals MSS.

Default Receive Window (RWIN) = 384000
RWIN Scaling (RFC1323) = 3 bits (scale factor of 6)
Unscaled Receive Window = 48000

For optimum performance, consider changing RWIN to a multiple of MSS.
Other values for RWIN that might work well with your current MTU/MSS:
513920 (MSS x 44 * scale factor of 8)
256960 (MSS x 44 * scale factor of 4)
128480 (MSS x 44 * scale factor of 2)
64240 (MSS x 44)
bandwidth * delay product (Note this is not a speed test):

Your RcvWindow limits you to: 15360 kbps (1920 KBytes/s) @ 200ms
Your RcvWindow limits you to: 6144 kbps (768 KBytes/s) @ 500ms
MTU Discovery (RFC1191) = ON
Time to live left = 51 hops

TTL value is ok.
Timestamps (RFC1323) = OFF
Selective Acknowledgements (RFC2018) = ON
IP type of service field (RFC1349) = 01011100

Precedence (priority) = 100 (flash override)
Delay = 1 (low delay)
Throughput = 1 (high throughput)
Reliability = 0 (normal reliability)
Cost = 1 (low cost)

mccoffee · Post by **mccoffee** » Thu Sep 16, 2004 9:37 am

what settiings did you use to get the speed because they look high as heck and it may cause promblems later on?? Stick with steele's numbers or try thease

DefaultReceiveWindow = 98304
DefaultSendWindow = 98304
DisableAddressSharing = 1
InitialLargeBufferCount = 200
InitialMediumBufferCount = 480
InitialSmallBufferCount = 640
LargeBufferSize = 819200
MaxFastTransmit = 64000
MediumBufferSize = 150400
PriorityBoost = 0
SmallBufferSize = 12800
TransmitWorker = 32
FastSendDatagramThreshold = 1024
EnableFastRouteLookup = 1
EnablePMTUDiscovery = 1
IgnorePushBitsOnReceive = 0
GlobalMaxTcpWindowSize = 64240
MaxFreeTcbs = 8000
MaxHashTableSize = 16384
MaxNormLookupMemory = 5000000
SackOpts = 1
SynAttackProtect = 1
Tcp1323Opts = 0
TcpLogLevel = 1
TcpMaxDupAcks = 2
TcpMaxHalfOpen = 100
TcpMaxHalfRetried = 80
TcpRecvSegmentSize = 1460
TcpSendSegmentSize = 1460
TcpTimedWaitDelay = 30
TcpUseRFC1122UrgentPointer = 0
TcpWindowSize = 64240
MaxConnectionsPer1_0Server = 10
MaxConnectionsPerServer = 8
DefaultTTL = 128
DisableUserTOSSetting = 0
TcpMaxDataRetransmissions = 6
DefaultTOSValue = 240

farmerbob · Post by **farmerbob** » Thu Sep 16, 2004 11:46 am

what potential problems could be seen with this setup? I know that according to broadband reports tweak tester my rwin is too high, but like it is it shows the highest transfer rate for file downloading as well as straight speed test. Are we talking about packet loss , reliability, or what?

mccoffee · Post by **mccoffee** » Thu Sep 16, 2004 5:51 pm

the tweak tester at dsl reports is not working with xp sp2 why becuase something in the tcpip stack got changed in sp2.

Defualt recive window in 2k/xp/2003 is not the actual rwin that is a buffer in the afd parameters

Tcpwindowsize is where you enter the rwin from sg or dsl reports

The tweak tester is now looking at default recive window which is not the rwin in 2k/xp. tcpmaxwindowsize is the rwin in /xp sp2/2003.

So you don't have a high rwin it's just that test and the analyzer is looking at the wrong thing.

even though it's the wrong thing i could tell in your cablenut settings that your default recive window is off it should be 98304 however it might come out wrong on this end so i don't know.

earthmofo · Post by **earthmofo** » Thu Sep 16, 2004 7:13 pm

Just FYI .

Actually, the Speedguide Analizer and DSLreports Tweak Test both report the DefaultReceiveWindow of AFD only if the value is present in the registry. If no value exists then they both report the correct RWIN (TcpWindowSize).

mccoffee · Post by **mccoffee** » Thu Sep 16, 2004 8:00 pm

earthmofo wrote:Just FYI .

Actually, the Speedguide Analizer and DSLreports Tweak Test both report the DefaultReceiveWindow of AFD only if the value is present in the registry. If no value exists then they both report the correct RWIN (TcpWindowSize).

Good point i forgot about that thanks earth

Post by **Philip** » Sat Sep 18, 2004 2:58 pm

mccoffee wrote:the tweak tester at dsl reports is not working with xp sp2 why becuase something in the tcpip stack got changed in sp2.

Defualt recive window in 2k/xp/2003 is not the actual rwin that is a buffer in the afd parameters

Tcpwindowsize is where you enter the rwin from sg or dsl reports

The tweak tester is now looking at default recive window which is not the rwin in 2k/xp. tcpmaxwindowsize is the rwin in /xp sp2/2003.

So you don't have a high rwin it's just that test and the analyzer is looking at the wrong thing.

even though it's the wrong thing i could tell in your cablenut settings that your default recive window is off it should be 98304 however it might come out wrong on this end so i don't know.

I am sorry but this is BS.

The Analyzer is looking at the only TCP Window value that is present in packets, the one and only value that is seen by servers. Period. Regardless of Operating system, regardless of Registry values, AFD, tcpip.sys, or whatever else.

And the Optimizer is fully capable of tweaking SP2 as well you don't necessarily need to use Cablenut.

earthmofo · Post by **earthmofo** » Sat Sep 18, 2004 5:12 pm

Philip wrote:I am sorry but this is BS.

The Analyzer is looking at the only TCP Window value that is present in packets, the one and only value that is seen by servers. Period. Regardless of Operating system, regardless of Registry values, AFD, tcpip.sys, or whatever else.

I agree. The real question is why is SP2 using the AFD parameter DefaultReceiveWindow (if the entry is present in the registry) for the TCP Window value in the packets?

Philip wrote:And the Optimizer is fully capable of tweaking SP2 as well you don't necessarily need to use Cablenut.

It's just a matter of preference. For novice users I suggest using Speedguide's Optimizer. Easy to use and very effective. Cablenut, I believe, is for advanced users. Many settings that can affect the connection and if misconfigured can render it slow and unstable.

mnosteele52 · Post by **mnosteele52** » Sat Sep 18, 2004 8:34 pm

Philip wrote:I am sorry but this is BS.

The Analyzer is looking at the only TCP Window value that is present in packets, the one and only value that is seen by servers. Period. Regardless of Operating system, regardless of Registry values, AFD, tcpip.sys, or whatever else.

And the Optimizer is fully capable of tweaking SP2 as well you don't necessarily need to use Cablenut.

This makes me curious then Philip, if you put a value in for DefaultReceiveWindow in CableNut or manually edit your registry then the TCP/IP Analyzer will read it rather the the TCPWindow value. As you know the DefaultReceiveWindow value is an AFD parameter but the TCPWindowSize value is a TCP/IP value. If you don't have anything in your registry for DefaultReceiveWindow then the TCP/IP Analyzer reads the TCPWindowSize value.

So the question to me is..... why is the TCP/IP Analyzer reading AFD registry values rather than TCP/IP registry values?

earthmofo · Post by **earthmofo** » Sat Sep 18, 2004 8:50 pm

It has something to do with SP2. The Analyzer only reads what is being reported as the Tcp Window value from the packets. Because of SP2 if there is a value present for DefaultReceiveWindow in the AFD parameters then that is the value it reports. If the entry is not present in AFD then it reports the TcpWindowSize value.

Microsoft had made quite a few security changes to TCP with SP2. We know that tcpip.sys has been changed but haven't heard of afd.sys being changed at all. More than likely it has which could be the reason for which value is being reported. It could also just be a bug that hasen't been corrected.

Post by **Philip** » Sat Sep 18, 2004 9:48 pm

Thanks earthmofo...

There are even more than two values in the Windows Registry. They all affect the same ONE RWIN value in packet headers that travel on the Internet. What RWIN Registry entry overrides the others in the Windows Registry is not important, as long as what goes into packet headers is correct. What goes in packet headers is one RWIN value, being affected by 3+ different Registry values. If you enter the AFD registry value, it might override the TCP Registry value... However, the order is not important, one must supercede the others... The end result is still one RWIN value that gets advertised to servers, one RWIN value in packet headers. That's what the TCP protocol supports, one RWIN value (and one scale factor).

Take a look at the structure of TCP headers, here is a good example: http://www.networksorcery.com/enp/protocol/tcp.htm

The 16 bit "Window" in that above link is the RWIN value being advertised. In addition, if the server recognizes TCP Options, there is a multiplier to that original 16 bit RWIN value.

The Analyzer looks at packets from clients, and extracts that ONE and ONLY Receive Window value from the headers, as well as the multiplier from TCP Options and everything else. It looks at the packets and does not differentiate between what your OS is, whether it has a Registry, and what values are in it. It takes the RWIN value directly from TCP headers, after capturing and disecting actual TCP handshake packets.

I can't say that other tools out there look at packet headers like the Analyzer. It required coding a server application that listens to incoming connections, something like a simplified web server. PC Pitstop on the other hand used to look at Registry values, I'm not sure about the one on DSLR. I know they use Java and I'm not sure they have the same capabilities and look at the same values as the SG TCP Analyzer.

Best,

Ph.

farmerbob · Post by **farmerbob** » Sat Sep 18, 2004 11:21 pm

wow you fellows sort of took my simple little problem and went waay over my head. So my question remains: what will I possibly see going wrong if my settings are too high? Things seem to be fine so far

Post by **Philip** » Sat Sep 18, 2004 11:51 pm

farmerbob wrote: wow you fellows sort of took my simple little problem and went waay over my head. So my question remains: what will I possibly see going wrong if my settings are too high? Things seem to be fine so far

The only disadvantage of having a too high RWIN value is you might experience a bit higher packet loss, if there is any. It would only occur in case your node is congested and packets are being dropped. The high RWIN value does not create packet loss by itself, just that more packets can be lost since there is more data hanging in the pipe... ( I hope I didn't confuse you further

).

To determine the correct RWIN value you should use, you take the maximum throughput of your connection (768Kbps) and multiply it by the maximum anticipated latency (let's assume 300ms)... But to leave the boring math out, the 256000 RWIN value is a bit high for your connection type, you can safely reduce it in half and get the same throughput.

mccoffee · Post by **mccoffee** » Sun Sep 19, 2004 6:52 am

The Analyzer looks at packets from clients, and extracts that ONE and ONLY Receive Window value from the headers, as well as the multiplier from TCP Options and everything else. It looks at the packets and does not differentiate between what your OS is, whether it has a Registry, and what values are in it. It takes the RWIN value directly from TCP headers, after capturing and disecting actual TCP handshake packets.

I'm not sure if i'm following you Phill

Don't you still need tcp.sys for a header if the registry plays no part. Ms even said in there hofixes for sp2 they patched tcp.sys if that has nothing to do with the analzyer then how would connect to the analyzer without that file you wouldn't you can't have a header without that protocol installed right ???

Boggles my mind this whole afd.sys tcp.sys thing.

Post by **Philip** » Sun Sep 19, 2004 9:39 am

You need tcpi.sys, the AFD and TCP parameters in the Registry and everything else that manages the TCP/IP protocol in Windows. If you have another Operating System, you'd have other files, possibly no Registry, but you'd still be able to communicate on the Internet. The common factor, all those files and settings are used to create packets at the end that travel on the Internet. Those packets, in order to be understood by routers, servers, and all network devices on the network follow the same standard - it being TCP / IP (well, they are actually 2 standard protocols, TCP and IP). TCP is "Transfer Control Protocol" and IP is the "Internet Protocol".

Those standard protocols are defined in RFCs, and what they basically do is add headers to every packet of information that travels on the Internet. 20-byte IP header, 20-byte TCP header and possibly some "TCP options" that add a few more bytes to the header. Every TCP/IP packet that travels on the Internet conforms to that same standard, regardless of your Operating System. When you connect to a server using TCP/IP, all the server understands is these protocols, they are the ones that define the headers and packets. Serves and other network devices do not understand Windows, they do not know about tcpip.sys or whatever else... All they have to know is that you are sending them a TCP/IP packet. Then, in the packet header there is information about the source IP address, destination IP address, sequence number of the particular packet, RWIN, etc. The network device then knows where to forward these packets, or if they have reached the destination - how to reassemble them into something meaningful. The destination device also gets RWIN and all the settings from the TCP/IP header of the packets.

All registry settings and other Windows files that form the TCP/IP protocol do is create such packets that travel on the Internet. The Analyzer looks at those packets, it does not know about your system's Registry entries or system files. Since those packets have to conform to the TCP/IP standard in order to reach the server, they already contain all the information that your PC is sending out on the Internet.

It gets only a bit more complicated than that - When you try to establish a TCP/IP connection to a server, there are 3 initial packets that establish the connection. They are called the "TCP Handshake". Those 3 packets are important in establishing the link and contain important settings in the headers.

That's all there is to it. Packets traveling independently on the Internet... Containing the source/destination address, information like RWIN... All getting reassembled at either end by the TCP/IP Protocol. Headers are like envelops, and MSS is the actual contents, or letter. All envelops contain the adresses and all the info needed to get to the destination. Linux, Windows, Mac OS-X, or whatever OS - all they have to do is implement the protocol and understand those packets in order to communicate.

I hope I'm making some sense.

earthmofo · Post by **earthmofo** » Sun Sep 19, 2004 10:09 am

The tcpip.sys that was included with SP2 had been updated for security reasons. It now allows only 10 concurrent open connections. It is supposed to help stop the spread of worms and trojans. It can create a lot of problems especially with P2P programs. With file shareing programs it is often possible to reach the 10 concurrent open connections limit. When this happens it prevents connections to all IP addresses that are in the loopback address range except for the localhost and you can't connect to the internet with a web browser for example.

The hotfix, you can read about here Microsoft Knowledge Base Article - 884020, that Microsoft issued to correct the problem increases the concurrent open connections to 50 but it seems that it only allow it on the local host only. Someone did patch the tcpip.sys to correct it and you can read about it here www.lvllord.de

Post by **Philip** » Sun Sep 19, 2004 10:51 am

earthmofo wrote:The tcpip.sys that was included with SP2 had been updated for security reasons. It now allows only 10 concurrent open connections. It is supposed to help stop the spread of worms and trojans. It can create a lot of problems especially with P2P programs. With file shareing programs it is often possible to reach the 10 concurrent open connections limit. When this happens it prevents connections to all IP addresses that are in the loopback address range except for the localhost and you can't connect to the internet with a web browser for example.

The hotfix, you can read about here Microsoft Knowledge Base Article - 884020, that Microsoft issued to correct the problem increases the concurrent open connections to 50 but it seems that it only allow it on the local host only. Someone did patch the tcpip.sys to correct it and you can read about it here www.lvllord.de

My rant on that

--> http://www.speedguide.net/read_articles.php?id=1497

Was that MS Hotfix intended to solve a different issue though, or was it direcyly related to the 10 connection attempts per second cap ?

earthmofo · Post by **earthmofo** » Sun Sep 19, 2004 12:44 pm

It was directly related. The fix was for Event ID 4226. I had it in my event log. I used lvllord's patched version of the fix and it hasn't occured since.

farmerbob · Post by **farmerbob** » Sun Sep 19, 2004 2:08 pm

well fellows, I tried running a smaller rwin(128480) first, then I decreased tcp window size from 128480 to 64240, and no matter which setup I had my speeds were slower and I ran the tweak tester and at all times it said I should decrease my rwin in the left column but in the middle column it said the applet loaded too slowly as if my rwin was too small. So it seems that for whatever reason my connection runs better with my rwin set at 384000 and tcp window at 128480

chpalmer · Post by **chpalmer** » Sun Sep 19, 2004 4:21 pm

Farmerbob- when you went with 64240 did you turn of windows scaling or tcp13230pts= 0 ?

farmerbob · Post by **farmerbob** » Sun Sep 19, 2004 7:39 pm

no I didn't change that setting. should i have, what does it do?

mccoffee · Post by **mccoffee** » Sun Sep 19, 2004 9:26 pm

that setting tcpipts123 allows widnows to use a rwin larger then 65535 so to get to 64240 you need that on 0 because 64240 is lower then 65535

chpalmer · Post by **chpalmer** » Sun Sep 19, 2004 9:29 pm

Also adds a small amount to the overhead although not much.

Post by **Philip** » Sun Sep 19, 2004 10:42 pm

[quote="chpalmer"]Also adds a small amount to the overhead although not much. ]
"Only" 12 bytes to each packet...

dannjr · Post by **dannjr** » Tue Sep 21, 2004 2:12 am

Sorry Farmerbob if its a little over your head in this but you asked

Ok I wont get started on this but it seems to me that some factors are being overlooked..
I'm not gonna do a right or wrong thing, just point out NEW things added to SP2 not discussed...
Winsock has been updated and AFD was originally based on security but also based on bits.. Ide love to give actual links but the list is extreemly long and some of the info out from MS is understandably hidden...

Bottom line getting into to high a Rwin without the rest of the proper settings makes for a bad day no matter how it reads..
TcpWindowSize when put in right is still valid no matter how its viewed in a analyzer.. However if the analyzer dosnt read the values correct AND Im not pointing at Speedguides Analyzer...(been discussed) Then it makes it hard to diagnose..

One last point allot of analyzer software is not reading correctly in XP SP2 as well as sniffers older network tools.. Most need to be updated fast.
The bad side to them being updated will be that SP2 will need a update to SP3

Just my opinion I could be wrong

(of course its late too)

hint: redirection is Uncle Bill Gates middle name now

Post by **Philip** » Tue Sep 21, 2004 11:28 am

Dannjr, I agree with what you've said.

Some of the "analyzing programs" out there may read registry or other Windows entries using Java or other means (rather than TCP packets directly), which allows for errors any time MS decides to change the implementation of the TCP/IP protocol in Windows.

On the other hand, the SG TCP Analyzer is completely OS independent and does not differentiate between Windows or other OSes - it simply understands the TCP/IP protocol and shows what is in the actual TCP/IP packets traveling on the net.

Best,

Ph.

farmerbob · Post by **farmerbob** » Tue Sep 21, 2004 9:22 pm

I don't understand all the terminology(such as afd), nor do I understand all the components that go into the makeup of a tcp/ip stack. So it's a little hard to understand exactly what the changes i make are going to do. With that said I want to clarify the tweak tester at bbr read my rwin correctly, but it's advice was that it should be lowered just like you guys say. Secondly I wanted to ask what you guys thought about the possibility that the reason my connection works the best with a seemingly too high rwin is that my isp only has 4 megabits of bandwidth total and they are using a kind of "homemade " bandwidth limiter, and I wondered if their bw limiter wasnt somehow affecting the traffic so that my rwinworks like it does. I hope you guys can make sense out of what i'm trying to ask

farmerbob · Post by **farmerbob** » Fri Sep 24, 2004 10:36 am

Post by **Philip** » Fri Sep 24, 2004 11:56 am

That is probably related to the way you test to determine what RWIN works better.

For example, if you download a comparatively small file (let's say the size of your RWIN value) there is no time for the download to settle and display the actual constant transfer speed. In other words, all the web based "speed tests" are unreliable.

The only way to reliably test is to pick servers that are far from you ( >10 hops ), then download large files and look at the average throughput.

Also, for example IE starts downloads early, it begins from the time you click "Save" to the time you pick a location on your HD and click OK... It will cache the amount of your RWIN on your end, so the beginning of your Download will always seem faster. That does not mean you're getting any better transfer speed....

I hope this helps

mnosteele52 · Post by **mnosteele52** » Fri Sep 24, 2004 12:00 pm

To add a little more to Philips post........

When a TCP/IP connection is created, the machines on either end agree upon RWINs for both directions. The upstream RWIN can never exceed the RWIN of the distant machine, and the downstream RWIN can never exceed the RWIN of the local machine.

Once the connection is negotiated, data transfer starts. The remote machine sends enough data to fill the RWIN of the local machine.

If the RWIN is at least as large as the modem cap times the round trip time (latency), no increase in the RWIN will produce a faster speed.

Things to keep in mind when tweaking.

earthmofo · Post by **earthmofo** » Sat Sep 25, 2004 7:01 pm

[quote="mnosteele52"]
If the RWIN is at least as large as the modem cap times the round trip time (latency), no increase in the RWIN will produce a faster speed.

Things to keep in mind when tweaking.

]

Steele, is the modem cap in bits or bytes? I'm assuming bytes since with a large cap the RWIN could be very high.

mnosteele52 · Post by **mnosteele52** » Sat Sep 25, 2004 10:59 pm

You are correct earthmofo

, bytes.

For those that do not understand, 500 times your caps in kilobytes is the largest value that you should ever use for your RWIN, any larger WILL NOT offer any increase in bandwidth.

For example with my caps of 4000/512 (that is in kilobits), convert it to kilobytes by dividing it by 8. 4000 / 8 = 500. So 500 x 500 = 250,000 is the largest RWIN that I should ever use and that value needs to be an even multiple of your MSS for optimum throughput. 250,000 / 1460 = 171.2, round up to 172 then multiply 172 x 1460 = 251,120 <-- that is the absolute largest RWIN value I should use.

This is why I don't agree with the patches here and the recommended RWIN values of 256,960 or 513,920 since they are both way too large for the vast majority of people. Especially when someones caps are 512, 768 or 1500 kilobits, values that large will only cause retransmitted packets thereby actually slowing your connection down.

SG Broadband Community

XP SP2 hows that work??

XP SP2 hows that work??

oh well

whoa

heck if I know

uh oh

maybe