SUMMARY: How to set PC/TCP parameters

5 views

Skip to first unread message

Doug Lucy

unread,

Feb 23, 1993, 1:04:38 PM2/23/93

Summary: Responses to "How to configure PC/TCP and Interdrive"

I queried the net with the following:

Article <1993Feb17.2...@sandr.COM>:

> I'm using FTP's PC/TCP version 2.05 with a WD/SMC 8013
> card on a Dos/Windows/DesqviewX 386 box and I'm getting
> rotten performance from my NFS-mounted drives.
>
> There's only the SCO ODT 1.1 server (using the same WD
> card and the LLI drivers EFS from SCO) and this DOS box on
> a single coax strand, but my NFS (PC/TCP's Interdrive)
> performance sucks.
>
> Using ftp makes transfers go quicker, but I want to use
> the DOS-visible NFS mounted drives.
>
> What parameters can I change and what series of steps
> should I take to test the transfer rate while changing the
> TCP/IP (ipcust and wd8003) and NFS driver (idrive and
> idconfig) parameters?

The following responded:

Date: Thu, 18 Feb 93 10:08:59 GMT
From: Henrik Kristensen <uk.locus.com!henrik@uunet>

We have experienced the same problems with PC-Interface
running over PC/TCP with the generic PC/TCP kernel. When
using packet drivers there seems to be no way of speeding
things up.

But if you use NDIS, you will have a line in the PROTOCOL.INI
secifying the software interrupt used by the kernel
(intvec=xx). There is another parameter called "chainvec"
which is normally commented out. We saw a 10-fold increase
in performance when specifying the chainvec. I cant remember
what interrupts we used, but the two must be different.

From: Dwight Ernest <hyphen.com!dwight@uunet>
Date: Fri, 19 Feb 93 13:01:23 EST

TCP/IP-based stuff like FTP will always outperform NFS for
two reasons:

1 - The NFS spec REQUIRES that the server use synchronous
writes on the clients' behalf. No caching is allowed. The
clients' writes may only be acknowledged when the
synchronous write to disk returns.

2 - NFS is (usually) implemenets on top of RPC, and RPC is
(usually, in this case) very poor at tricks like windowing.
(Ask me if you don't know what that means). RPC is itself
implemented on top of UDP, which cannot guarantee things
like packet ordering or guarantee delivery (unlike TCP).
So it's slower for this reason, too.

But the synchronous writes are the real killer.

You can mitigate this with buffer size adjustments, etc.,
and you're headed in the right direction, but if you expect
it ever to be as fast as, say, FTP, you'll be disappointed.

Date: Fri, 19 Feb 1993 13:01:54 +0100 (MEZ)
From: Michael Mattes <mu...@samser.gold.sub.org>

Well, i've got about the same configuration and at first was
also wondering about the performance ... until someone told
me that this is caused by the large protocol-overhead of
TCP/IP _and_ a bad implementation of some of the routines
by SCO.

At least the latter statement has proved to be true, because
with the new ODT 2.0 the transfer-rate is about 40-70 %
higher.

I'm not a protocol-expert enough to verify the fact that a
10 Mbit/s network could carry so much garbage to deliver
only about 900 kbit/s :-(

My transfer-rate (SCO 2.0, measured with ftp) is about 100-
150 kB/s.

Date: Mon, 22 Feb 93 10:19:53 -0500
From: ftp.com!ravi@uunet (Ravi Prakash)

> From sandr!dl...@uunet.UU.NET Sun Feb 21 01:08:27 1993
> Subject: How to set PC/TCP parameters for best performance
>
> I'm having trouble setting the paramters on IFCONFIG,
> IPCONFIG and IDRIVE to increase the performance of my two
> machine LAN.
>
> I'm using WD8013 cards, each in a 386 ISA machine, one
> running SCO OpenDesktop 1.1 Unix 3.2.2 and one running
> MS-DOS 5.0 and PC/TCP 2.05
>
> The ftp performacne to/from the SCO box isn't bad, but the
> performance of INTERDRIVE-mounted NFS volumes on the DOS
> box is poor.
>
> What steps should I take to tune the performance of the
> DOS side of the connection (i.e. IDRIVE, IDUTIL, etc)?

idconfig.exe has an option "-e' which can be used to change
the effective MTU. Even if you are on an ethernet, if you
will eventually use media which has a smaller MTU, your
effective MTU should reflect this. For example:

idconfig -e drive 512

*******************
fine tuning idrive:
*******************

One thing to know is that writes take longer then reads.
Here are a few things you can try. The following options
are all provided for setting idrive's read and write
transaction sizes. This is important for a variety of
reasons.

1) Large transactions mean fewer transactions. Given that a
large percentage of the time for each transaction is used up
in per-transaction overhead. larger packets will give "much"
better performance. This is the main reason why lack of
outgoing IP fragmentation causes major performance problems.

2) However, if you are going across a WAN, where your packets
might get fragmented and some of the fragment's dropped.
Then packets small enough to survive fragmentation might
perform better. (NOTE that UDP unlike TCP does *NOT* have a
mechanism for determining *switch* of the fragments may have
been dropped).

3) Early versions of the SUN NFS Reference Port were buggy
and many older NFS servers will crash if you give them read
sizes other than multiples of 1024. (write operations were
*usually* OK)

idconfig -e drive value set the Effective MTU for drive
`drive to value' bytes
config file: mtu=value

Most physical networks place an upper limit on the size of a
packet that they will transmit. This is called the Maximum
Transmissible Unit (MTU). Unless told to do otherwise,
idrive will select read and write sizes based on the
requested transfer size of the server and the MTU of the
connected network as provided by the PC/TCP kernel. Note
that due to protocol overhead, the read/write sized must be
significantly smaller than the MTU.

This option allows you to specify an "effective" MTU that may
differ from the real MTU. If, for example, your packets are
going through a gateway that will fragment packets larger
than 512 bytes, then it would be useful to set the read and
write sizes to let the packets fit inside the "effective"
MTU of 512.

idconfig -r drive value set Read size for drive to
value bytes
config file: reads=value

This option allows you to explicitly set the read size to a
given value (as long as it doesn't exceed the MTU).
Depending on the server, the best results are obtained with
either 1024 or the maximum that will fit into the MTU.
Since some servers will crash for values of other that 1024,
this defaults to 1024.

idconfig -w drive value set Write size for drive to
value bytes
config file writes=value

This option allows you to explicitly set the write size to a
given value (as long as it doesn't exceed the MTU). In
general, best results are obtained using the largest value
that will fit within the MTU, but some servers will do
better with a value of 1024. This defaults to the maximum
for a given MTU.

Idrive will NOT allow you to set an "effective MTU" larger
than the MTU of the connected network.

idconfig -i drive reinitialize tuning parameters for drive

This one doesn't have a config file option. It exists for
those times when you have been mucking about with the
configuration and want idrive to re configure itself based
on the MTU of the connected network. In general, this will
set effective MTU to the MTU of the connected network, read
size to 1024, and write size to the maximum it can fit into
the MTU.

If you have any additions, corrections or suggestions, please send
them to me and I'll re-mail them to those interested.

Reply all

Reply to author

Forward

0 new messages