Re: Anyone running Linux 2.0 + squid > beta 7?

From: k claffy <kc@dont-contact.us>
Date: Thu, 13 Jun 1996 17:32:17 -0700 (PDT)

   
speaking of running certain OSes,
i have a marginally related favor to ask
ircache/squid folks. we are trying to determine
some parameters of various OSes for
high performance computing --
we're building a table at
        http://www.nlanr.net/perf_tune.html

if anyone has clues about the blank lines in
the table at the bottom here,
[specifically we're missing HPUX, linux, macos,
all windows os's, netbsd, and solaris...]
we'd be most grateful for your wisdom --

[the page is definitely worth a read,
thought it's being updated often, --
we hope... ]

----------------------------------------------------

In order to take advantage of today's high speed networks, hosts must
support and utilize extensions to basic TCP/IP. There are four main steps
required for both the data sender and data receiver:

    1.The host systems must use Path MTU Discovery (RFC1191). This
      allows systems to use the largest possible packet size, rather than
      the default of 512 bytes. On most systems, this feature must be
      explicitly enabled by the system administrator. If Path MTU
      Discovery is unavailable or undesired, it is sometimes possible to
      trick the system into using large packets, but this may have
      undesirable side effects.

    2.The host systems must support RFC1323 "Large Windows"
      extensions to TCP. These extensions enable new features in the
      TCP/IP protocols needed for high speed transfers. On some
      systems, RFC1323 extensions are included but may require the
      system administrator to explicitly turn them on.

    3.The host system must support large enough socket buffers for
      reading and writing data to the network. Typical Unix systems
      include a default maximum value for the socket buffer size between
      128 kB and 1 MB. For many paths, this is not enough, and must be
      increased. (Without RFC1323 "Large Windows", TCP/IP does not
      allow applications to buffer more the 64 kB in the network, which is
      inadequate for almost all high speed paths.)

    4.The application must set its send and receive socket buffer sizes (at
      both ends) to at least the bandwidth*delay product of the link. (See
      computing bandwidth*delay products below). Some user
      applications support options for the user to set the socket buffer size
      (for example, Cray UNICOS FTP); many do not. Alternatively, the
      system-wide default socket buffer size can be raised, causing all
      applications to utilize large socket buffers. This is not generally
      recommended, as many network applications then consume
      system memory which they do not require.

      For socket applications, the programmer can choose the socket
      buffer sizes using a setsockopt() system call. A Detailed Users
      Guide describing how to set socket buffer sizes within socket based
      applications has been put together by Von Welch at NCSA.

         Support for these features under various operating systems

                                      Default Default Default
    Operating maximum TCP UDP Applications
     System Path MTU RFC1323 socket socket socket (if any)
 (Alphabetical) Discovery Support buffer buffer buffer which are
                                       size size size user tunable
                                                       9216
 BSDi No Yes 256kB 8kB snd None
                                                       41600
                                                       rcv
 ConvexOS 11.0 Yes 2400kB
 CRI Unicos 8.0 Yes Yes FTP
 Digital Unix
 3.2 Yes 128kB None
 FreeBSD 2.1.5 Yes Yes 256kB 16kB 40kB
 HPUX ???
 IBM AIX 3.2 &
 4.1 No Yes 64kB 16kB None
 Linux
 MacOS (Open
 Transport) Yes No
 Microsoft
 Windows NT
 Microsoft Win95
 NetBSD
 SGI IRIX 5.3 Yes Yes 512kB 60kB None
 SGI IRIX 6.1 Yes Yes 1MB 60kB None
 SGI IRIX 6.2 Yes Yes Unlimitted 60kB None
 Sun Solaris 2.5
Received on Thu Jun 13 1996 - 17:32:56 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:32:30 MST