TCP/IP tuning

I want to tune my tcp/ip to perform with large (~500MB) file transfer in
ftp. I use SuSE Linux Pro 9.0 and a gigabit ethernet. Should I use the
jumbo frame, etc?

Thank you,
Jean-Philippe.

"Jean-Philippe Blais" <(E-Mail Removed)> wrote in message
news:FUlbd.120114$(E-Mail Removed) ...
>I want to tune my tcp/ip to perform with large (~500MB) file transfer in
>ftp. I use SuSE Linux Pro 9.0 and a gigabit ethernet. Should I use the
>jumbo frame, etc?

I may be jumping ahead of myself here but since you are offering a service
to your "clients" I don't see how you can use jumbo frames. There is no way
all these desktops can handle more than the standard 1522 bytes packets. And
I don't think there are lot people wiht GIGE.

--Turi

Aditya Ivaturi a écrit :

> "Jean-Philippe Blais" <(E-Mail Removed)> wrote in message
> news:FUlbd.120114$(E-Mail Removed) ...
>
>>I want to tune my tcp/ip to perform with large (~500MB) file transfer in
>>ftp. I use SuSE Linux Pro 9.0 and a gigabit ethernet. Should I use the
>>jumbo frame, etc?
>
>
> I may be jumping ahead of myself here but since you are offering a service
> to your "clients" I don't see how you can use jumbo frames. There is no way
> all these desktops can handle more than the standard 1522 bytes packets. And
> I don't think there are lot people wiht GIGE.
>
> --Turi
>
>

Hi,

it is not to offer a service to client, it is for inter-server
communication. The ftp part is only my test bench.

My major concert is about TCP buffers and window size, allocate more
memory to it and tune networked machine for network perdormance.

Thanks,
JP.

Aditya Ivaturi <(E-Mail Removed)> wrote:
> "Jean-Philippe Blais" <(E-Mail Removed)> wrote in message
> news:FUlbd.120114$(E-Mail Removed) ...
>>I want to tune my tcp/ip to perform with large (~500MB) file transfer in
>>ftp. I use SuSE Linux Pro 9.0 and a gigabit ethernet. Should I use the
>>jumbo frame, etc?

> I may be jumping ahead of myself here but since you are offering a
> service to your "clients" I don't see how you can use jumbo
> frames. There is no way all these desktops can handle more than the
> standard 1522 bytes packets. And I don't think there are lot people
> wiht GIGE.

Well... he _could_ enable JumboFrames, he just wouldn't get any
benefit from it when/if all the clients exchanged non-Jumbo MSS
values. He'd also have to be very careful about any UDP traffic his
machine might source.

"In the datacentre" (as it were) there probably wouldn't be an issue
with JF, and it would certainly make life easier on most things
concerned (stack, DMA, busses etc).

On the 2.6 kernels and some NICs, there is the option of TSO (large
send) or what might be called "poor man's jumbo frame" that would
benefit the sender almost as much as JF, but would do nothing for the
receiver. For long-lived (subjective) connections TSO would be OK, but
if you are concerned about slow-start, you need to be on a later 2.6
kernel (IIRC something at/past 2.6.8.1 in kernel.org naming - I am
still very fuzzy on kernel naming, so if I've botched that, please be
gentle

Making sure that FTP is using a "large enough" window is goodness.
You could try-out some settings with netperf TCP_STREAM or
TCP_SENDFILE tests (not sure how many FTP's on Linux use sendfile().
I'd probably then add a skosh more to acount for the FS overheads.

rick jones
--
a wide gulf separates "what if" from "if only"
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to raj in cup.hp.com but NOT BOTH...

Jean-Philippe Blais wrote:
> I want to tune my tcp/ip to perform with large (~500MB) file transfer in
> ftp. I use SuSE Linux Pro 9.0 and a gigabit ethernet. Should I use the
> jumbo frame, etc?


You'll win little if your connection is not a long fat pipe,
e.g. intercontinental satellite link. You'll get plenty of
problems, however, if you try to deviate from the standard
framing.

TCP is pretty clever to use the best flow you can get for
the available connection.

The achievable improvement is rather a few percent instead
of tens of percents. The same applies to full duplex, as
long as the transfer is one direction only.

Tauno Voipio
tauno voipio (at) iki fi

>
> Well... he _could_ enable JumboFrames, he just wouldn't get any
> benefit from it when/if all the clients exchanged non-Jumbo MSS
> values. He'd also have to be very careful about any UDP traffic his
> machine might source.

If he turns in JF, that means, if I am understanding you right, you are
implying JF and standard can co-exist(?). Can you shed a little more light
on this? What I am trying to find out is that is it possible to send packets
in boht JF and standard and the "clients" (be it server or otherwise) chose
which packet they can handle. Now on the hindsight, if you are sending same
data in two different packet formats are you effectively improving
performance or degrading it? Just trying to analyze the options available.

--Turi

> it is not to offer a service to client, it is for inter-server
> communication. The ftp part is only my test bench.

If it is between servers by all means. In fact it is much better to do it
that way.

Aditya Ivaturi <(E-Mail Removed)> wrote:
> If he turns in JF, that means, if I am understanding you right, you
> are implying JF and standard can co-exist(?). Can you shed a little
> more light on this? What I am trying to find out is that is it
> possible to send packets in boht JF and standard and the "clients"
> (be it server or otherwise) chose which packet they can handle. Now
> on the hindsight, if you are sending same data in two different
> packet formats are you effectively improving performance or
> degrading it? Just trying to analyze the options available.

At the beginning of a TCP connection, both ends exchange MSS options.
Those will be based on a number of factors, including local MTU.

So, when a TCP on a JF host sends his MSS option it will be 8XXX
bytes. The client on a non-JF host will send 1460 bytes (or whatevev)
and 1460 byte TCP segments will be exchanged on the connection.

That only "works" because the two endpoints in TCP exchange MSS
requests. For UDP traffic, there is no MSS exchange, so there is
nothing to "cover" for the MTU mismatch when one host on a switch is
JF and another not.

As such, it is something that is "possible" but perhaps not
"preferable." One really does want all systems in the same broadcast
domain (switch fabric, or same "side" of a router) to have the same
MTU.

rick jones
--
a wide gulf separates "what if" from "if only"
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to raj in cup.hp.com but NOT BOTH...