Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP
id AA6243 ; Wed, 06 Jan 93 07:02:56 EST
Xref: sserve comp.unix.bsd:9724 comp.sys.sgi:25990 comp.sys.sgi.apps:39
Path: sserve!manuel.anu.edu.au!munnari.oz.au!uunet!olivea!sgigate!sgi!rhyolite!vjs
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.unix.bsd,comp.sys.sgi,comp.sys.sgi.apps
Subject: Re: Problem to transfer large data via socket communication - Need Help
Message-ID: <ukhu2k8@rhyolite.wpd.sgi.com>
Date: 8 Jan 93 18:33:40 GMT
References: <1993Jan8.071612.13716@news.uni-stuttgart.de> <1ikdakINN3tn@uther.cs.purdue.edu>
Organization: Silicon Graphics, Inc. Mountain View, CA
Lines: 54
In article <1ikdakINN3tn@uther.cs.purdue.edu>, spaf@cs.purdue.edu (Gene Spafford) writes:
> Oliver asks about how large a buffer can be sent at once using
> sockets.
>
> The problem is not really one of buffer size, at least not at the
> level of read/write calls. The underlying transport mechanism between
> machines has a limit. For instance, standard Ethernet packets will
> have a limit of about 1500 bytes each (depending on headers, trailers,
> etc). The network software and hardware will need to do fragmentation
> and reassembly of whatever buffers you have so as to meet these
> limits. The only possible savings you get by bigger buffers in the
> user calls are by reducing the number of calls into the OS to
> accomplish the transmission -- and that cost is usually far outweighed
> by the network latency involved.
>
> If you are trying to speed up large transfers, the places to optimize
> are in the number of bytes actually sent (can you compress the data
> somehow?), the protocols used (possibly reduces the size of
> headers/trailers that need to be transmitted, reducing latency), and
> in using better routes (faster lines, less switching).
>
> Of course, these comments only hold if you are sending the data off
> the machine. If you are communicating between sockets on the same
> machine, you are much better off using shared memory and avoiding
> sockets entirely.
Since the original note appeared in comp.sys.sgi.* and so may be about
a particular brand of machine, I will presume to disagree.
TCP buffer transfers on SGI machines run much faster on bigger buffers,
except when limited by the medium. There are many reasons for this,
from reductions in the number of system calls to reductions in the
number of times bytes are copied when buffers are large and well
behaved to other things. There is a point of diminishing returns,
which on FDDI for us happens around 32KB or 64KBytes with small TCP
windows. With larger windows, really large buffers can be nice.
On the other hand, if there ethernet or slower is being used to move
the data, then the medium will be the bottle neck for buffer sizes
above 1 or 2KB. Given that 4.3BSD style TCP buffers user data in the
kernel, it might be effective to "pipeline" the application. If the
sending application can be structured as:
while (not_done) {
generate_a_few_KB_of_data();
send_a_few_KB();
}
and similarly on the receiving side, then the time required to for the
data to squeeze over the ethernet might be at least partially
overlapped by the time required to actually generate or use the data,
or to read or write the data to or from files.
Vernon Schryver, vjs@sgi.com