I would like to those people below for their help -- Casper for helping me
to sort through the Solaris patches and drivers; Herbert for assistance in
tuning experiments; Elaine for sharing some related experiences; Kjersti and
Per for publishing a tremendous paper on this topic, although wholly in the
SunOS domain. And a host of others who told me that NFSv3 is for v2.5 and up.
Casper Dik <casper@holland.Sun.COM>
Herbert Leitold <hleitold@iaik.tu-graz.ac.at>
Elaine Reynolds <reynolds@nicanor.acu.edu>
Kjersti Moldeklev <kjersti.moldeklev@tf.tele.no>
Per Gunnningberg <per@sics.se>
To reiterate the problem, we were seeing data transfer rates well under
ethernet values (10 Mb/s) over the ATM between our hetergenous network of
SunOS 4.1.3_u1 and Solaris 2.4 hosts. Another group controls the Solaris
hosts, while my group controls the legacy SunOS hosts -- but the equipment
must all work together when delivered to a common customer network.
The bottom line is that the Solaris hosts had already been tweaked to push
their TCP buffers and window size up to the maximum of 64K. The SunOS hosts
were still running with default 16K buffers. These didn't mix well. My
solution was to modify the behavior on the SunOS side. This may be done
without editting in_proto.c and building a new kernel as follows:
# echo "tcp_sendspace/W 0x8000" | adb -kw /vmunix /dev/mem
# echo "tcp_recvspace/W 0x8000" | adb -kw /vmunix /dev/mem
In the example above, the value of 32K (0x8000) may be replaced with any
hex value under 51K. Not all of our SunOS hosts have ATM adaptors, so I
elected to modify the /etc/rc.local, testing first for the ForeIP interface
(fa0), and then applying the above if found.
For anyone still working these matters in the SunOS domain, the paper by
Moldeklev and Gunningberg may be very helpful. I found it located at
ftp.fore.com:/pub/docs/papers/ifip94.ps. Advances in the Fore products
(ASX-200BX vs. ASX-100) have eliminated the cell loss charted therein at the
maximum buffer sizes. It's also interesting to note that the Solaris /dev/tcp
driver appears to be impervious to the [mis]application of send/receive buffer
sizes that created the deadlock situations which they discussed in detail.
Kirk
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:47 CDT