Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!olivea!mintaka!spdcc!dirtydog.ima.isc.com!ism.isc.com!b1!ico!dougm
From: dougm@ico.isc.com (Doug McCallum)
Newsgroups: comp.unix.sysv386
Subject: Re: ISC TCP/IP 1.2 hangs?
Message-ID: <1991Jun20.140559.19011@ico.isc.com>
Date: 20 Jun 91 14:05:59 GMT
References: <1991Jun06.224153.209@pinhead.pegasus.com> <4104@merk.UUCP> <1991Jun11.152602.22404@ico.isc.com> <1991Jun18.184744.357@heitis1.uucp>
Reply-To: dougm@ico.ISC.COM (Doug McCallum)
Organization: Interactive Systems Corp., Boulder CO
Lines: 42

In article <1991Jun18.184744.357@heitis1.uucp> news@heitis1.uucp (News Administrator) writes:
...
>If the WD8003 driver for TCP/IP v1.2 is the same as that supplied in the
>Network Drivers Supplement available back around march, it has one major
>problem.  (According to people at ISC).  The buffer in the WD8003 8-bit card
>is something like 128 or 256 bytes.  The buffer for the WD8003 16-bit card
>is double whatever the other one is.  The driver was written expecting the
>larger buffer, and will sometimes "overflow".  Also, you cannot use an
>8-bit card with a 16-bit card as a gateway, apparently it just loses its
>mind entirely.

This is nonsense.  The WD8003* boards have an 8K buffer.  The WD8013 cards
may have an 8 or 16K buffer depending on versions, bus, etc.  The driver
was written originally with the ability to use any buffer size.  The very
first version was written using an 8K card (serial number 6 if I remember
correctly) and makes absolutely no assumptions about a minimum or maximum
buffer size.

There is an internal "page" size of 256 bytes that is used by the hardware
but this is not something that effects performance.

An 8K card can overflow if used under heavy load or if packets are sent
at it too fast.  In this case it discards the packet that won't fit in the
receive buffer.  It doesn't lose its mind.  What you were told just sounds 
like someone making up an excuse when they don't understand a problem.

Where you will get real problems is in mixing 16-bit and 8-bit cards
on the same system.  The first Network Drivers Supplement didn't go
through the contortions necessary to work around the wonderful feature
of the AT bus where ALL memory access in the 128K region the board's
RAM appears in must be in 16 bit mode.  This is compensated for in the
second release of the drivers (I don't know if it is shipping yet or not).
To compensate requires a lot of work to avoid what happens if you don't.

If you have the bus in 16 bit mode and try to access 8 bit RAM, you get
trash (well, consistent trash of 0xFF) in the odd bytes.  This is a design
feature of the bus and is the same reason you get problems with 16 bit
VGA boards and 8 bit LAN boards at the same time.

Doug McCallum
Interactive Systems Corp
dougm@ico.isc.com