I posted yesterday about a one-directional FTP speed problem I was
experiencing when using PCNFSPro 1.1 with a Sun running SunOS 4.1.4 -
this problem has been solved. My original post is attached at the end
of this summary message.
The Respondees:
--------------
I received three responses from (thanks!):
carlo_musante@hub.eng.wayne.edu Carlo Musante
kevin@anymore.more.com Kevin Sheehan
<allan@mazama.com Christopher A. Stewart
and thanks to any more people with suggestions "in the mail".
The Suggestions:
---------------
"Carlo Musante" <carlo_musante@hub.eng.wayne.edu>
I would try using a different driver for PC-NFS. We were using
NDIS with PC-NFS 5.0 and 5.1. We had to switch to ODI on some
of our machines. FTP perofrmance was miserable. Small files
were transferable but as the file size increased through put
decreased almost exponentially.
I just checked the copy of PC-NFSpro I am testing and recieved
230kb thoughput both for puts and gets. My test machine is
still using the ODI drivers with the ODI packet shim. Looks
like the ODI drivers work with FTP and PC-NFSpro. I am using
the default configuration for PC-NFSpro and ftping to a SunOS
4.1.3U1 machine.
kevin@anymore.more.com (Kevin Sheehan {Consulting Poster Child})
I'd take a look with snoop and/or etherfind and see which side
is imposing the delay. At least that will allow you to narrow
down the culprit.
"Christopher A. Stewart" <allan@mazama.com>
Actually this is a hardware and software configuration issue.
The problem resides in the 3C509, it has an 8k buffer (most
3COM cards do, while several other cards have 16k buffers.)
When ever possible TCP/IP uses 8k buffers for data, then breaks
it up into the MTU packet size. This means the 8k buffer fills
up with data. this means in the 3com card there is a traffic
jam in the buffer between data going out and acks coming in.
You correct this by setting the max data buffer to 4k. I know
this is possible for NFS generally, not sure about ftp though.
The Solution:
------------
The award goes to Carlo! The 3C509 packet driver is the apparent real
culprit here. When I switched to the included NDIS drivers, the problem
went away. Now I can get close to 800 kBytes/sec when sending data from
the PC to the Sun and about 400 to 550 kBytes/sec when transferring
data from the Sun to the PC (The factor of two here is irrelevent - it
was the tremendous factor of 20 or more in the original case that had
me worried yesterday). I have not had to go to ODI as Carlo found
necessary in his environment on some machines.
I also tried changing the NFS read/writes to 4096 bytes as Christopher
suggested - without luck. The driver change is what did the trick for
me! Clearly the Crynwyr packet driver has some problem in it that
affects the results I observed (repeatably and I can duplicate it - I
tried it again for grins). Since the sources for that packet driver
program are included, I may do some digging someday and see if I see
anything funny in the source code - although this may wait for a rainy
day since browsing through Intel assembly is not my idea of fun <grin>!
Z
-------------------------------------------------------------------------
| Syed Zaeem Hosain P. O. Box 610097 (408) 441-7021 |
| Z Consulting Group San Jose, CA 95161 szh@zcon.com |
-------------------------------------------------------------------------
The Original Message:
--------------------
> The Systems:
> -----------
>
> First test:
>
> System 1: Sun IPX, SunOS 4.1.4
> System 2: 486DX/33 PC with PCNFSPro 1.1, DOS 6.22, Win 3.1
> DOS 6.22
> 3COM 3C509 ethernet card (using Packet driver)
>
> Second test:
>
> System 1: Sparc 2 clone, SunOS 4.1.4
> System 2: 486DX4/100 PC with PCNFSPro 1.1, DOS 6.22, Win 3.1
> 3COM 3C509 ethernet card (using packet driver)
>
> The Problem:
> -----------
>
> I am seeing a bizarre problem with a Sun and PC with ftp speeds that I
> do not understand. Basically, I have a Sun and PC (recently switched
> from PCNFS 5.0 to PCNFSPro 1.1) where the ftp data transfer speeds in
> one direction are pretty pathetic.
>
> With PCNFS 5.0 (in DOS and Windows 3.1), I got about 250 to 300
> kBytes/sec when transferring data from the PC to the Sun and about 350
> to 400 kBytes/sec when going the other way. Both times I was running
> ftp on the PC only and the data measurement was on an isolated network
> between two systems.
>
> This was not too bad for most data transfers. I attributed the lack of
> higher rates (across the 10Mhz ethernet pipe) to the 16 bit nature of
> the PC programs, since with Windows NT and its built-in TCP/IP support,
> I can get about 700 to 800 kBytes/sec, in both directions, between a PC
> and a Sun).
>
> With PCNFSPro 1.1 (in Windows 3.1 only, of course), when running ftp on
> the PC, I see about 700 kBytes/sec when transferring data from the PC
> to the Sun and about 30 kBytes/sec going the other way. When running ftp
> on the Sun, I see about 350 kBytes/sec when going from the PC to the
> Sun and about 10 kBytes/sec going the other way!
>
> What I have tried:
> -----------------
>
> I have tried everything I can think of to explain this and but to no
> avail. In the NFS setup section of the PCNFSPro setup, I tried changing
> the read block size from 1024 bytes to 8192 bytes, but this only made
> things worse transferring data from the PC to the Sun (particularly
> with writing to a Sun disk mounted as "D:" - this is a pain as it is my
> PC backup method using Norton Backup) and had no effect on the ftp
> performance. So I changed this back.
>
> Netstat reports that the MTU is set to 1500 bytes, so this is probably
> not a fragmentation problem.
>
> The traffic on the networks is totally minimal, in particular, one of
> the networks was a dedicated two-system setup (PC and Sun) and nothing
> else was being used.
>
> Neither machine reports network i/o errors (from "netstat") so the
> network cabling is all right. Plus, the PCNFS 5.0 ran okay in both
> directions just before the software was changed - with identical
> hardware. Changing the network back to PCNFS results in the same
> performance as before.
>
> In any case, I have now tried this on two networks, with two entirely
> different PC and Sun systems (listed above), with almost identical
> results (although both *were* using packet drivers and similar 3COM
> 3C509 cards - 10Base2 in one case and the AUI jack in the other). So
> this is something inherent in the PCNFSPro software.
>
> Does anyone know what is going on? And how to fix the problem? I have
> been spending time on this since Friday morning, without any luck, and
> now need to find a solution for this problem as soon as possible!
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:25 CDT