Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP
id AA7686 ; Mon, 25 Jan 93 12:20:03 EST
Xref: sserve comp.unix.bsd:10363 alt.sources:5037
Newsgroups: comp.unix.bsd,alt.sources
Path: sserve!manuel.anu.edu.au!munnari.oz.au!uunet!emba-news.uvm.edu!hal.emba.uvm.edu!wollman
From: wollman@hal.emba.uvm.edu (Garrett Wollman)
Subject: [386BSD] Fourth Release, i82586 Ethernet driver
Message-ID: <1993Jan23.194050.635@uvm.edu>
Sender: news@uvm.edu
Organization: University of Vermont, EMBA Computer Facility
Date: Sat, 23 Jan 1993 19:40:50 GMT
Lines: 209
I am pleased to announce the release of the latest version of my
i82586-based Ethernet device driver. This driver is currently known
to work on AT&T EN100 and StarLAN 10 controllers, but the job of
porting it to another card should be simple.
>From the NEWS file:
Changes from the Third Release of this driver:
- Support for IP multicasting.
- ieattach() correctly fills in its link-level address, so `netstat -i'
gives useful information:
ie0 1500 <Link>08.00.6a.81.14.15 391 0 328 0 0
- ieattach() also correctly fills in the link type information, so
that if the hack is finally removed from if_attach(), it won't
require changing.
- More bugs hopefully eliminated.
- More support for the StarLAN Fiber adapter (but it still doesn't work).
------------------------------------
The entire README file follows.
README
Fourth Release
Intel i82586 Ethernet controller driver
Copyright 1992, Garrett A. Wollman
Copyright 1992, University of Vermont and State Agricultural College.
See permission notice at end.
INTRODUCTION
This package consists of a driver for the Intel high-performance
8-/16-bit LAN controller, the i82586. The mode in which it currently
operates is known to be correct for a standard DIX version 2.0
Ethernet, but may not be correct for some other network systems, such
as StarLAN. The only network hardware currently supported is the AT&T
EN100 NAU, operating in Ethernet mode, but the software was designed
to allow support for other controllers to be easily integrated;
indeed, only three functions need to be written in order for other
standard Ethernet cards based on this controller to work. (The
Clarkson Packet Drivers should show you what needs to be done.)
The package as it stands does not support trailers. I see no
particularly good reason for it to do so, since no modern network
hardware emits such ugly packets. Eventually, I will try to
support Paul Tsuchiya's PIP in addition to IP, NS, and 802.2.
INSTALLATION
To install this driver, you will first need to add the line
if_ie.c optional ie device-driver
to your /sys/i386/conf/files.i386 file. Once this is done, you should
add a configuration file entry similar to the one included in my
configuration file, TSORNIN. Then re-run `config', `make depend', and
`make'. With luck, you will have a fully-functioning kernel with a
network interface called `ie0'. (You should be able to configure more
than one, but I've never tried this myself.)
You can then add
ifconfig ie0 inet my-address netmask my-netmask broadcast my-broadcast
to your /etc/netstart, and away we go!
PERFORMANCE
Well, to be quite honest, performance was not one of my major goals.
Indeed, I expect transmit to be quite a dog, since I only queue up a
single transmit command. However, receive performance should be quite
improved from the previous version (which died on large packets
anyway), as the new version takes note of the fact that most packets
are relatively small, and so uses a received frame area consisting of
32 received frame descriptors (so a maximum of 32 frames can be
received while waiting for interrupt service) and 32 256-byte receive
buffers. The driver itself also takes pains to free up un-needed
receiver resources as soon as possible, to reduce the number of
interrupts which must be processed. (The device interrupt routine
also polls the 586 status register to keep immediate turnarounds down
to a minimum.)
I tested the TCP performance of my machine, tsornin, against sal, an SGI
4D/210S (which used to be a 220, 230, and 240). First, to get a
baseline, I tested the loopback interfaces:
For tsornin:
------------------------------------
ttcp-r: socket
ttcp-r: accept from 127.0.0.1
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp
ttcp-r: 16777216 bytes in 127.32 real seconds = 128.69 KB/sec +++
ttcp-r: 4997 I/O calls, msec/call = 26.09, calls/sec = 39.25
ttcp-r: 0.1user 38.1sys 2:07real 30% 0i+0d 0maxrss 0+0pf 156+4719csw
------------------------------------
For sal:
------------------------------------
ttcp-r: socket
ttcp-r: accept from 127.0.0.1
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp
ttcp-r: 16777216 bytes in 14.68 real seconds = 1116.02 KB/sec +++
ttcp-r: 2049 I/O calls, msec/call = 7.34, calls/sec = 139.57
ttcp-r: 0.0user 2.3sys 0:14real 15% 220maxrss 0+0pf 14+966csw
------------------------------------
The next test measures tsornin's receiver; this includes one cisco
router hop:
------------------------------------
ttcp-r: socket
ttcp-r: accept from 132.198.3.22
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp
ttcp-r: 16777216 bytes in 134.31 real seconds = 121.99 KB/sec +++
ttcp-r: 16777216 bytes in 23.83 CPU seconds = 687.54 KB/cpu sec
ttcp-r: 4123 I/O calls, msec/call = 33.36, calls/sec = 30.70
ttcp-r: 0.1user 23.7sys 2:14real 17% 0i+0d 0maxrss 0+0pf 4116+166csw
ttcp-r: buffer address 0xc000
------------------------------------
Finally, tsornin's transmitter (and, of course, also sal's receiver),
still one hop:
------------------------------------
ttcp-r: socket
ttcp-r: accept from 132.198.4.5
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp
ttcp-r: 16777216 bytes in 101.18 real seconds = 161.93 KB/sec +++
ttcp-r: 16340 I/O calls, msec/call = 6.34, calls/sec = 161.49
ttcp-r: 0.1user 7.4sys 1:41real 7% 220maxrss 0+0pf 16334+32csw
------------------------------------
ACKNOWLEDGEMENTS
This driver would not have been possible without the help of several
individuals:
- The authors of the Clarkson Packet Drivers
- Terry from Novell
- Somebody from Labtam whose name I've forgotten
- Steve Ackerman for lending me a copy of his i82596 manual
- Dr. Gary Barbour for not complaining about the amount of time I
spent making this work right.
- The United States Postal Service, for losing our order to Intel for
a '586 manual.
I would appreciate it if any new additions or extensions of this
driver are communicated directly with me, rather than letting a
mish-mash of different versions float about.
CONTACTING THE AUTHOR
You can contact me via electronic mail (preferred) as
<Garrett.Wollman@UVM.EDU>. You can send paper mail to me at 127 Saint
Paul Street #218, Burlington, VT 05401.
COPYING
Here are the conditions attached to this software:
Copyright (c) 1992, University of Vermont and State Agricultural College.
Copyright (c) 1992, Garrett A. Wollman.
Portions:
Copyright (c) 1990, 1991, William F. Jolitz
Copyright (c) 1990, The Regents of the University of California
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software
must display the following acknowledgement:
This product includes software developed by the University of
Vermont and State Agricultural College and Garrett A. Wollman,
by William F. Jolitz, by the University of California,
Berkeley, by Lawrence Berkeley Laboratory, and its contributors.
4. Neither the names of the Universities nor the names of the authors
may be used to endorse or promote products derived from this software
without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE UNIVERSITY OR AUTHORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.
--
Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ...
wollman@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance.
uvm-gen!wollman | It is a bond more powerful than absence. We like people
UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant