Date: Sun, 21 Mar 93 04:30:11 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #77
To: tcp-group-digest
TCP-Group Digest Sun, 21 Mar 93 Volume 93 : Issue 77
Today's Topics:
Ethernet Problem
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: 20 Mar 93 18:35:28 EST
From: Steve Dworkin <70730.220@CompuServe.COM>
Subject: Ethernet Problem
To: Advanced Amateur Radio G <tcp-group@ucsd.edu>
Relayed by N2MDQ:
I'm having a problem running NOS on an ethernet that I just can't seem
to get a handle on. Below is a diagram of my mini network:
Host1 Host2 Host3
[386/16]---------------[486DX2-66]----------------[386/16]
Hardware/software:
8-bit I/O bus 16-bit I/O bus 8-bit I/O bus
JNOS 1.07b JNOS 1.07b JNOS 1.07b
DOS 5.0 DOS 5.0 DOS 5.0
QEMM386 6.02 QEMM386 6.02 QEMM386 6.02
3C501 NE2000 or 3C501 or 3C505 3C501
Packet Driver v10 Packet Driver v10 Packet Driver v10
The problem that I'm having is with Host2 during ftp sessions to either
Host1 or Host3. If Host2 sends a file to either of the other two
systems at least 25 percent of the ethernet frames are shown as retried
via tcp view bytes, however, if Host2 is receiving a file, less than 1
percent of the frames are being retried. If Host1 initiates an ftp to
Host3, or Host3 initiates an ftp to Host1, very few frames are retried,
and transfer rates are between 26 to 30 kb/sec depending on how well
primed the disk cache is.
Originally, I thought that there might be a problem with the 3C501, so
I tried an NE2000, and a 3C505 in Host2, but I got the same results.
I've replaced the cabling, T-connectors, and terminators on the
network. All network cards pass diagnostics with flying colors.
The memory statement for each host is:
memory nibufs 4
memory ibufsize 1522
The attach packet statement for all three systems as:
attach packet 0x60 4 1500
The relavant tcp statements are:
tcp mss 1460
tcp window 5840
The ifconfig statements for all three hosts is:
ifconfig ec0 mtu 1500
ifconfig ec0 rxbuf 6000
Changing the window and/or frame size offers no help. I've also
tinkered with the memory ibufsize statement changing it from 1522
(starting point) up and down, and the memory nibufs from 5 to 10, etc.
The packet driver statement used for all three systems is:
<drivername> 0x60 2 0x300.
Other sessions, ie. ping, telnet, etc. appear to work fine. On
traces, it appears that frames are being sent out by Host2 'too fast'
for the other hosts to acknowledge, as they don't appear to even see
the initial frames. I've also tried changing the IRQs and DMA channels
in all three systems.
Changing versions of JNOS (1.05 to 1.08c) and also to GRINOS 2.0m
doesn't help.
I've attempted to ipl the systems from a 'plain vanilla' diskette, also
with the same results.
Can anybody help me see the light of day? I am extremely perplexed.
Is
there something about the way a 486DX2 handles the bus? In the source
for the packet drivers, there was a comment about the 486 processor.
Is there something that I'm missing in the configuration of the three
systems?
Thanks in advance!
Jan Smoller - KC2CT [44.68.8.55]
Reply here or direct to 70730.220@compuserve.com
------------------------------
End of TCP-Group Digest V93 #77
******************************
******************************