# TCP tweaking (RWIN and the likes)

## dsd

Hi,

I've been having trouble with my connection lately, an engineer came out today to take a look. He's done some work on the hardware side but made some suggestions to how I could improve the software configuration. He didn't know linux so couldnt advise me how.

He showed me this site: http://www.speedguide.net/analyzer.php

And pointed out that my RWIN is way too low.

```
Default Receive Window (RWIN) = 5840

RWIN Scaling (RFC1323) = 0 bits

Unscaled Receive Window = 5840
```

He says that the windows default is usually around 64000, but he recomends registry tweaks to increase this to much much higher. On some sites I found recommended values ranging from 300000 to 800000.

Visiting the speedguide analyzer on windows, i get this output:

```
Default Receive Window (RWIN) = 64240 

RWIN Scaling (RFC1323) = 0 bits 

Unscaled Receive Window = 64240 

```

A similar page: http://syntest.psc.edu:7961/ (I trust this one more because my port 80 is transparently proxied by my ISP).

Through linux:

```
!

! Check of SYN options

!

!=======================================================

! Variable        : Val       : Warning (if any)

!=======================================================

SACKEnabled       : 3         :

TimestampsEnabled : 0         : WARN - Timestamps option is not enabled

CurMSS            : 1460      :

WinScaleRcvd      : 0         : WARN - 0 WinScale Received

CurRwinRcvd       : 5840      :

!

! End of SYN options

!
```

Through win2k default:

```
SACKEnabled       : 3         :

TimestampsEnabled : 0         : WARN - Timestamps option is not enabled

CurMSS            : 1460      :

WinScaleRcvd      : 4294967295:

CurRwinRcvd       : 64240     :

```

So basically, I'd like to increase my RWIN. I've done some googling and have come out with these commands:

```
echo 0 > /proc/sys/net/ipv4/tcp_timestamps

echo 1 > /proc/sys/net/ipv4/tcp_window_scaling

echo 1 > /proc/sys/net/ipv4/tcp_sack

echo "372300" > /proc/sys/net/core/rmem_default

echo "372300" > /proc/sys/net/core/rmem_max

echo "372300" > /proc/sys/net/core/wmem_default

echo "372300" > /proc/sys/net/core/wmem_max

```

However, after running those TCP analyzer pages again, my RWIN is still 5840.

Any ideas?

----------

## Braempje

I tought there was a kernel option you had to turn on to adjust tcp window settings etc.

----------

## neenee

i've been looking for a way to set those

options as well. with windows they seem-

ed to make a difference; maybe they

will improve something with linux as well.

----------

## dsd

 *Braempje wrote:*   

> I tought there was a kernel option you had to turn on to adjust tcp window settings etc.

 

any idea which one? theres quite a lot of network options, none jump out from the crowd for this functionality.

----------

## gizmo.tar.bz23

just have a look at

/proc/sys/net/core/rmem_max

----------

## dsd

thanks for the reply, but i already tried that one (i set it in my series of commands from my search on google). doesnt help  :Sad: 

----------

## dsd

bump.. still havent found an answer  :Sad: 

----------

## neenee

hm. i will do a proper search across the net in a moment.

i'll report back with whatever i find. even if it is nothing.

hm.. the only thing i found was that a large receive win-

dow is only necessary when a connection is made with

a large delay (200+ms).

and i found many people asking the same thing; how to

make a setting and have it saved an used by linux.

----------

## dsd

thanks for looking.

 *neenee wrote:*   

> hm.. the only thing i found was that a large receive win-
> 
> dow is only necessary when a connection is made with
> 
> a large delay (200+ms).

 

that may be true, but then again, delays in data transfers can be caused by a low RWIN value. assume a situation where a remote server is sending you data: when the recieve window has been filled, the remote server will stall sending any more data until an ACK is recieved from you (the client). a small delay is introduced there (quite large delay when you got a flakey upstream like me). a larger RWIN results in less ACK'ing, fewer delays.

im usually not too bothered by these things, but a value of 5840 seems strikingly low.

----------

## sschlueter

 *dsd wrote:*   

> 
> 
> He says that the windows default is usually around 64000, but he recomends registry tweaks to increase this to much much higher. On some sites I found recommended values ranging from 300000 to 800000.
> 
> 

 

5840 is just the default receive window. If net.ipv4.tcp_window_scaling is set, then the receive window is adjusted dynamically. 

And btw the largest windows size is 65535. Higher values are not possible because it's stored in a 16 bit field. (rfc1323 describes the idea of an "implicit scale factor" but I'm unsure if that's implemented in Linux.)

Anyway, the problems with your network connection must have another reason.

----------

## dalu

 *sschlueter wrote:*   

>  *dsd wrote:*   
> 
> He says that the windows default is usually around 64000, but he recomends registry tweaks to increase this to much much higher. On some sites I found recommended values ranging from 300000 to 800000.
> 
>  
> ...

 

digging up an old thread,

this sounds good in theory, but it doesnt scale anything

 *Quote:*   

> 
> 
> Default Receive Window (RWIN) = 5808
> 
> RWIN Scaling (RFC1323) = 0 bits
> ...

 

```

!

! Check of SYN options

!

!=======================================================

! Variable        : Val       : Warning (if any)

!=======================================================

SACKEnabled       : 3         :

TimestampsEnabled : 1         :

CurMSS            : 1440      :

WinScaleRcvd      : 0         : WARN - 0 WinScale Received

CurRwinRcvd       : 5808      :

!

! End of SYN options

!

```

----------

## dsd

this was a looong time ago, but in the end i seem to remember finding a utility that measured RWIN over a continued transfer.

basically, the transfer starts off at 5808 and then rapidly increases. apparently the way that the linux tcp stack does it is much better than using a big fixed size.at this point i decided that the network engineer didn't really know what he was on about  :Smile: 

----------

## neenee

hurray  :Wink: 

----------

## TyroneSlothrop

Just some information for people finding this thread in the future...

The receive window is used for flow control. You can read about it for example in the following excerpt of "Computer Networking: A top down approach featuring the internet":

http://gaia.cs.umass.edu/kurose/transport/segment.html (Especially 3.5.6)

And here's something about congestion control:

http://gaia.cs.umass.edu/kurose/transport/congestion.html

And i think that you can be absolutely sure that it nearly never makes any sense at all to "tweak" the kernel. The people who hack it know what they are doing, and *if* there was a simple way to gain a lot of performance, it would *surely* be the default.

----------

## andyknownasabu

Some further information concerning this issue:

The following LWN article covers "window scaling" and mentions problems which arose after adding support for this feature in version 2.6.7-mmx of the linux kernel and Linus's BitKeeper tree.

Take a look - very interesting article and gentoo is also mentioned ;)

http://lwn.net/Articles/92727/

----------

## hmiller68

Sorry for dragging up an old thread but has any one gotten the RWIN to stay set after e reboot?

----------

## jbarry

For anyone searching the words RWIN or getting that "RWIN seems to be set to a very small number" advice from SpeedGuide.net TCP/IP Analyzer, there's no need to waste time on this non-issue, according to . . .

http://en.wikipedia.org/wiki/TCP_window_scale_option

 *Quote:*   

> Linux kernels (from 2.6.8, August 2004) have enabled TCP Window Scaling by default. It chooses the good value of the option by default. The configuration parameters are found in the /proc filesystem, see pseudo-file /proc/sys/net/ipv4/tcp_window_scaling and its companions /proc/sys/net/ipv4/tcp_rmem and /proc/sys/net/ipv4/tcp_wmem (more information: man tcp, section sysctl).

 

cat those /proc files to see what you've got.

----------

