# Thread: TCPWindowSize - Need Help with the Math

1. ## TCPWindowSize - Need Help with the Math

Okay, so I'm trying to figure out why these tweaks are making my connection so unstable and I think I've pinned it down to MaxConnectionsPerServer as well as an issue with the TCPWindowSize. With regards to MaxConnectionsPerServer, using default of 2, my router does not shut down port 80 as much when I try to view pages who consider multiple connections a DoS attack. However, port 80 still seems to like to shut down on me so I believe this has something to do with either the router or the TCPWindowSize (my router can not be flashed stably so I will assume TCPWindowSize is my next best bet).

So I'm trying to understand scaling and so on with Maximum Segment Size (MSS). Can someone help me understand this:

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)
Can someone expain where the 44 came from? That was extracted from the windows 2000/xp tweaking guide. I can understand the 1460, but where did the 44 come from? If I have an MTU of 1492, how do I calculate the proper scaling using a MSS of 1452?

2. I think you have some misunderstanding.

To check if MaxConnectionsPerServer is an issue to certain websites, connect your comp directly to the modem and use MaxConnectionsPerServer with value of 10. If you can surf the webpages in a normal way, the problem is most probably in the setup config of your router.

An appropriate RWIN is calculated in two steps. The first step is to determine the size using this formula

RWIN = Bandwidth x Max. Latency divided by 8

Eg. Bandwidth or subscribed speed = 3000 kbps
Max Latnecy is 170ms

RWIN = 3000 x 170 / 8 = 63750

The second step is to look for a RWIN value which is an even multiple of MSS.

eg. MTU = 1492 and so MSS = MTU - 40 = 1452

63750 / 1452 = 43.90, so we choose the even multiple of 44

Use RWIN = 1452 x 44 = 63888

TCP Analyzer carries recommendations from the base of 44 and then scaled factors of it. But in some MTU values (1452) the base can be 46 instead.

The reason for 44 is that for the most common MTU values of 1500 and 1492, 44 is the highest even multiple to obtain the highest RWIN that is below 65535. Any RWIN value above 65535 requires window scaling to be turned on, thus increasing packet overheads and reducing data carrying capacity of each packet.

So if MTU is 1452, MSS is 1412 and RWIN = 1412 x 46 = 64952 which is less than 65535.

3. Actually you dont need to check windows scalling. If you need for some latency reasons RWIN more than 65535, windows xp activates automatically windows scalling. Maybe some of you disagree witn this opinion, because its not written, but it works

4. Thanks for the information. I read around a bit more to try to get a good RWIN. Testing around, I went through DSLReports to get a good number through their speed test to get an average latency. It seems to be working well now. Pages load faster and my connection has been mostly stable. I just find it very odd how when I use a RWIN of 256960, I would constantly get problems (i.e., port 80 locks out until I change my IP number) if MaxConnections were more than 2. However, when I upped the RWIN to 501104, MaxConnections at 10 works fine.

I think another weird issue is that when I had my TTL at 64, certain pages would be slow to load or not load at all. So from that, I set it to 32 and things seem to be working mostly okay now.... any other general suggestions?

5. Sounds like your OS is not Windows.

6. Originally Posted by trogers
Sounds like your OS is not Windows.

oh, this is definitely Windows 2000 SP4. The more and more I tweak this, the more I'm feeling it is an issue with my router... Netgear FWG114P. I thought this was the best thing on the planet next to sliced cheese/bread.... but man, the more I began to work with the 5 units I bought, the more I hated them. Issues I ran into:

• Flashing the firmware on any of the 5 units I had made it unstable (yes, i properly flashed and reboot/reset/cleared the units)
• Certain "stable" firmware causes router lockup with certain port forward functions
• Router overly sensitive to TCP/IP tweaks as being DoS/Syn/TearDrop attacks
• USB Print server is extremely unstable when print errors occur
• Tech support was JUNK: they thought I was scamming them by registering 5 different serials for the same kind of unit

Although when the router works, I love it! And also, they look great... solid steel construction. But seriously, so unstable firmware. And also, trying to figure out what's causing my HTTP traffic to lockout..... although at the moment, the increase in my RWIN from 256960 to 511104 seems to do the trick.

7. Originally Posted by singularity2006
...although at the moment, the increase in my RWIN from 256960 to 511104 seems to do the trick.
RWIN at 256960 is for MTU 1500 and RWIN at 511104 is for MTU 1492.

Is there a mismatch of MTU setting between your Windows Registry, the router, and the ISP?

All 3 MTUs should be the same.

8. Originally Posted by trogers
RWIN at 256960 is for MTU 1500 and RWIN at 511104 is for MTU 1492.

Is there a mismatch of MTU setting between your Windows Registry, the router, and the ISP?

All 3 MTUs should be the same.
AH, I had no idea about the 1500 @ 256960. I originally set it at 256960 with 1492. As for my current settings, everything including the setting in the router is at 1492. I originally opted to use 1492 as using 1500 prevented me from logging into various https:// servers. However, now that you mention it, using an incorrect RWIN with an MTU - would that cause that kind of problem? If so, I might actually try increasing MTU across the board up to 1500 to see what happens..

On another note though, I did try using an MTU of 1500 once and when I ran it through the SG TCP/IP analyzer, it still said my MTU was 1492. Any particular reason for this?

9. Originally Posted by singularity2006
using an incorrect RWIN with an MTU - would that cause that kind of problem? If so, I might actually try increasing MTU across the board up to 1500 to see what happens..

On another note though, I did try using an MTU of 1500 once and when I ran it through the SG TCP/IP analyzer, it still said my MTU was 1492. Any particular reason for this?
The MTU value to use depends on your ISP's system and not a choice we can make. For Cable and PPPoA, MTU is set at 1500. For DSL and ADSL with PPPoE, MTU is set at 1492.

You need to find out what system your ISP is running and follow it.

For MTU of 1492, RWIN should be set to 127776 for speed 4-6 mbps and set to 255552 for speed 7-10 mbps. RWIN at 511104 is for speed above 10 mbps. Using too high a RWIN will cause slowdowns.

10. Originally Posted by trogers
For MTU of 1492, RWIN should be set to 127776 for speed 4-6 mbps and set to 255552 for speed 7-10 mbps. RWIN at 511104 is for speed above 10 mbps. Using too high a RWIN will cause slowdowns.
Thanks for the info. I will have to try adjusting the RWIN downward when I get home. Your help has been invaluable, many thanks! As for the PPPoE MTU, I remember doing a ping test to figure out MTU and got a funny result that allowed me an MTU of 1500.... is that possible at all for PPPoE?

11. Originally Posted by singularity2006
I remember doing a ping test to figure out MTU and got a funny result that allowed me an MTU of 1500.... is that possible at all for PPPoE?
No. Usually when we send out packets at MTU 1500 on a PPPoE system, we get fragmentation.

You can use the following with TCP Optimizer to find out the largest MTU of your ISP:

General Settings tab:
Custom settings - check
Modify All Network Adapters - check
MTU - 1500
TTL - 64
TCP Receive Window - leave blank
MTU Discovery - Yes
Black Hole Detect - No
Selective Acks - Yes
Max Duplicate ACKs - 2
TCP 1323 Options:
Windows Scaling - uncheck
Timestamps - uncheck
Max Connections per Server - 10
Max Connections per 1.0 Server - 20
LocalPriority - 5
Host Priority - 6
DNSPriority - 7
NetbtPriority - 8
Lan Browsing speedup - optimized
QoS: NonBestEffortLimit - 0
ToS: DisableUserTOSSetting - 0
ToS: DefaultTOSValue - 80
MaxNegativeCacheTtl - 0
NetFailureCacheTime - 0
NegativeSOACache Time - 0
LAN Request Buffer Size - 32768
Then select "Apply Changes" and reboot to take effect

After reboot, do the TCP Analyzer to find out your resulting MTU value.

12. Hey, thanks for the tip! Got it to 1492 with a RWIN of 127776 and so on so forth. So far everything is quite stable and working well with all of your help. However, I did run into issue with BitTorrent while tweaking things out. While downloading through BitTorrent, the download and upload were nowhere near maximum bandwidth but it caused all my HTTP traffic to timeout. Does the nature of BitTorrent require a larger RWIN, or does it not matter? And could it simply be an issue of BitTorrent itself causing issues with HTTP since it does open many many many simultaneous TCP connections with all the peers on the network?

And lastly, does a lower TTL value have any advantage? I tried 64 and 32 and in some instances, 32 yielded faster page loads (probably because of a faster re-transmit because of the lower TTL) but it was not always consistent. Your thoughts?

And again, thanks for all your help!

13. P2P does open many many connections, both in UDP and HTTP traffic. I use PeerGuardian 2 to reign in on bogus traffic. You can download this free software at http://phoenixlabs.org/pg2/

You will also need to increase your half-opened TCP concurrent connections from 10 to 50, but I use 64. This patch is available at http://www.lvllord.de/?lang=en&url=downloads

Keep your TTL to 64. Time to live (TTL) is just a setting in a data packet that specifies how many hops the packet can travel through before it is discarded by intermediate routers. This is to reign in lost packets. Having too small a value may cause packets not being able to reach you from web servers. Having it too large causes unnecessary congestions of lost packets in the networks.

14. With regard to the half-open TCP connections, is this also a problem within Windows 2000 or was it Windows XP SP2 only? Currently, I can get torrent downloads between 150K/sec to 300K/sec sustained. What will opening these concurrent connections do when I'm already getting near what my ISP's bandwidth will allow?

15. Oops. Yes, the patch is only for XP SP2 as Microsoft set a default limit in this OS to 10.

Other OS should not need this patch.

16. Thanks for the tip. I'll have to go into uTorrent to make the adjustment as default is only 8.... u said u use 64? I might try upping it next time I have Bleach or Naruto to download...

And thanks for all your help over the past couple of days... do u sleep at all? It's 1 a.m. PST right here and I'm very surprised to see you still replying so regularly!

17. Originally Posted by singularity2006
I can get torrent downloads between 150K/sec to 300K/sec sustained. What will opening these concurrent connections do when I'm already getting near what my ISP's bandwidth will allow?
It is mid-afternoon here in Bangkok, Thailand and probably 2-3am at your location in the US. My bed time would be 11am to 7pm your time.

If 300 KB/s (2400 kbps) is near your subscribed speed, I would recommend you try RWIN at 63888 to see if you get a more stable speed.

18. Cool Cool, have a good night!

So over the morning, I started surfing and downloading and doing all sorts of crazy things (opening email, IE, AIM, MSN, Yahoo, uTorrent, simultaneously) and I realized I was still having issue with all the various combinations of RWIN using scaling on and off (this issue seemed to pop up most when I start loading multiple web pages or loading several apps that make connections to the internet). It reminded me of an article I read long ago about MTU and thought I would share it here:

So I set my MTU to 1454 as described by that article and adjusted my RWIN accordingly. So far, no timeouts AND pages and sites load much more quickly (I used to get this weird delay when it was searching for the page)..! Anyway, I'll keep tweaking around as necessary to see what's going on. For now, your thoughts on MTU 1454?

19. When you mentioned that you have page display problems and logging into MSN, AIM etc when using MTU 1492, I have a suspicion that you are not in the US but rather is in the UK.

I believe this issue of MTU is basically that of the ISP's network system.

The principle of setting MTU to maximum value possible (MTU 1500 and MTU 1492) has been tried and tested and is still being used by majority of ISPs worldwide.

But there are some ISPs' networks that do not employ these 2 values and have set their own. Eg. AOL DSL limits MTU to 1400 and a few ISPs in the UK, esp those linked to British Telecoms (BT) find lower MTU values perform better.

Here is a Netgear guide on setting lower MTU values:

http://kbserver.netgear.com/inquira/...74#__highlight

EDIT: If you are using MTU 1454, I believe RWIN should be set to MSS x 46 (or MSS x 46 x 2 if you are in the UK).

20. Good afternoon/morning there!!

Yes, I actually read that very same article. However, that was a long time ago before I started really understanding the issues of RWIN with regard to MTU. But at that time, when I set it to 1400, my connection went to hell in a hand cart. ACtually, the 1454 seems to be working quite well now with all your help explaining how the calculations go. It is much much much more stable at 1454 as compared to 1492 (both with scaling OFF). And yes, I understand that my 65044 RWIN with 1454 MTU limits my bandwidth to 2.5Mb but on my bandwidth tests, I've never been able to get past that limit anyway so having scaling off to achieve my goal of stability works for me.

As for the MTU that Netgear recommends, it cannot be because of the ISP because I know that SBC here uses 1492 regularly. Netgear probably wrote up that article to cover the @ss for developing buggy routers..... seriously, I've never had such a bad time with their routers until I hit their ProSafe line.....

And yes, I am in the US, not UK. :]

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•