using route command to alter TCP window size

The 'route' command with a 'window' argument doesn't seem to work as
documented...

I've got two Linux systems (one a 2.4, one a 2.6 kernel) on the ends of
a long haul network. The rtt is ~ 68 millisec.

The slowest link is 100 megabit, so to get the max possible performance
I want to use the 'window' argument to route to bump up the TCP window
size for that particular host-to-host transfer (rtt * 100 Mbit is
~850kbytes).

I have altered the kernel var such as proc/sys/net/core/{w,r}mem_max to
8 MB, the ../ipv4/tcp_{w,r}mem to a max of 4 MB so that the window size
should get used.

It never does, that is not by default. If I use a test program that
calls setsockopt to ask for a 2 MB buffer, I get a 7 MB/sec or so rate,
which approachs the top rate of 12.5 MB/s I might asymptotically ger. If
I let it use the default sizez or alternatively, if I use FTP, I get
about 900 kilbytes/sec.

What am I doing wrong? When I did this with Solaris machines on either
en, the equivalent Solaris route command does have the expected behavior
of changing the default window size for connections to the target network.
--
Bill Wyatt ((E-Mail Removed)) "remove this" for email
Smithsonian Astrophysical Observatory (Cambridge, MA, USA)



WilliamREMOVEWyattTHIS

WilliamREMOVEWyattTHIS <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> The 'route' command with a 'window' argument doesn't seem to work as
> documented...

man route again -- the window arg is meant for "shrinking" the window
size in AX.25 (TCP/IP for ham radio operators).

> I've got two Linux systems (one a 2.4, one a 2.6 kernel) on the ends of
> a long haul network. The rtt is ~ 68 millisec.

Wan? PPP? Intervening networks and/or routers? What's the physical
make-up of this long haul network?

> The slowest link is 100 megabit, so to get the max possible performance
> I want to use the 'window' argument to route to bump up the TCP window
> size for that particular host-to-host transfer (rtt * 100 Mbit is
> ~850kbytes).
>
> I have altered the kernel var such as proc/sys/net/core/{w,r}mem_max to
> 8 MB, the ../ipv4/tcp_{w,r}mem to a max of 4 MB so that the window size
> should get used.

I think you've confused these socket buffer space settings with TCP
connection/header flags. They are inter-related re: connection
performance, but changing the socket buffers will not automagically
optimize the TCP window size (max 64KB) or window scaling (another 16
bits used to scale the window size). The auto-tuning keeps improving
but a few more tweaks are needed.

> It never does, that is not by default. If I use a test program that
> calls setsockopt to ask for a 2 MB buffer, I get a 7 MB/sec or so rate,
> which approachs the top rate of 12.5 MB/s I might asymptotically ger. If
> I let it use the default sizez or alternatively, if I use FTP, I get
> about 900 kilbytes/sec.

Sounds more and more like you have a dedicated link connecting the
ends.
And it sounds like you're familiar enough with the topic to ferret out
the additional tweaks (though be warned FTP can be a bear, sometimes
-- like NFS)

> What am I doing wrong? When I did this with Solaris machines on either
> en, the equivalent Solaris route command does have the expected behavior
> of changing the default window size for connections to the target network.

You'll find many anomolies like this between Solaris and Linux -- same
command, same switches but different behavior :-(

You're not too far off the mark, I think. But with a dedicated link
and apps you'll have to figure out the particulars -- we may be able
to help here and there ;-)

You can try here for a first go:
http://www-didc.lbl.gov/TCP-tuning/TCP-tuning.html
You likely already have this:
http://ipsysctl-tutorial.frozentux.n...tml/index.html
which gives an explanation of the variables in /proc/sys/net/xxx
This is my standard perf reference (concise but pretty complete):
http://www.psc.edu/networking/perf_tune.html
and this may be of interest too:
http://www.web100.org/

Just so you're aware
http://lwn.net/Articles/91976/
"TCP window scaling and broken routers"

Usually, I want to put a sniffer (ethereal) on the wire to see how the
windows are are behaving -- and avoid at all costs a window size of 0
;-)

To be honest it's been several years since I worked on this seriously
and since you're running a 2.6.x kernel I'm not sure how performance
has changed, but I think above should carry you a ways farther --
you're on the right track ;-)

hth,
prg
email above disabled