Commit | Line | Data |
---|---|---|
d30b4617 GW |
1 | |
2 | Release Notes for 'ed' Device Driver | |
3 | David Greenman, 24-May-1993 | |
4 | ------------------------------------ | |
5 | ||
6 | Last updated: 22-November-1993 | |
7 | ||
8 | INTRODUCTION | |
9 | ------------ | |
10 | The 'ed' device driver is a new, high performance device driver supporting | |
11 | the Western Digital/SMC 80x3 series (including 'EtherCard PLUS' 'Elite16' and | |
12 | 'Ultra'), the 3Com 3c503 (both 8 and 16 bit versions), and the Novell NE1000/ | |
13 | NE2000. All of the ethernet controllers use the DS8390, 83C690, or 83C790 | |
14 | Network Interface Controller (NIC). The differences between the boards are in | |
15 | their memory capacity, bus width (8/16 bits), special logic (asic) used to | |
16 | configure the board, and the host access method to the NIC memory (shared or | |
17 | programmed I/O). Every effort has been made to conform to the manufactures' | |
18 | specifications for the NIC and asic. This includes both normal operation and | |
19 | error recovery. | |
20 | ||
21 | PERFORMANCE | |
22 | ----------- | |
23 | ||
24 | transmit | |
25 | -------- | |
26 | The 8390 doesn't provide a mechanism for chained write buffers, so it is | |
27 | very important for maximum performance to queue the next packet for | |
28 | transmission as soon as the current one has completed. On boards with 16k or | |
29 | more of memory, the NIC memory is divided in a way that allows enough space | |
30 | for two full size packets to be buffered for transmission. When sufficient | |
31 | data is available for transmission, a packet is copied into the NIC memory, | |
32 | the transmission is started, and then an additional packet is copied into the | |
33 | NIC memory (to a different memory area). As soon as the first packet has | |
34 | completed, transmission of a second packet can then be started immediately. | |
35 | This results in nearly the highest performance possible from ethernet. | |
36 | ||
37 | Packets go out on the 'wire' with the following format: | |
38 | ||
39 | preamble dest-addr src-addr type data FCS intr-frame | |
40 | 64bits 48bits 48bits 16bits 1500bytes 32bits 96bits | |
41 | ||
42 | With 10Mbits/sec, each bit is 100ns in duration. All of the above fields, | |
43 | except for data are of fixed length. With full sized packets (1500 bytes), the | |
44 | maximum unidirectional data rate can be calculated as: 6.4us + 4.8us + 4.8us + | |
45 | 1.6us + 1200us + 3.2us + 9.6us = 1230.4us/packet = 812.74382 packets/second = | |
46 | 1219115.7 (1190k) bytes/second. With TCP, there is a 40 byte overhead for the | |
47 | IP and TCP headers, so there is only 1460 bytes of data per packet. This | |
48 | reduces the maximum data rate to 1186606 bytes/second. With TCP, there will | |
49 | also be periodic acknowledgments which will reduce this figure somewhat both | |
50 | because of the additional traffic in the reverse direction and because of the | |
51 | occasional collisions that this will cause. Despite this, the data rate has | |
52 | still been consistantly measured at 1125000 (~1100k) bytes/second through a TCP | |
53 | socket. In these tests, the TCP window was set to 16384 bytes. With UDP, there | |
54 | is less overhead for the headers, and with 1472 bytes of data per packet, a | |
55 | data rate of 1196358.9 (1168k) bytes/sec is possible. UDP performance hasn't | |
56 | been precisely measured with this device driver, but less precise tests show | |
57 | this to be true (measured at around 1135k/second). | |
58 | ||
59 | receive | |
60 | ------- | |
61 | The 8390 implements an NIC memory ring-buffer to store incoming packets. | |
62 | The 8bit boards (8003, 3c503, and NE1000) usually have only 8k bytes of shared | |
63 | memory. This is only enough room for about 4 full size (1500 byte) packets. | |
64 | This can sometimes be a problem, especially on the original WD8003E and 3c503. | |
65 | This is because these boards' NIC memory access speed is also quite slow | |
66 | compared to newer 16bit boards - typically less than 1MB/second. The additional | |
67 | overhead of this slow memory access, and the fact that there is only room for 4 | |
68 | full-sized packets means that the ring-buffer will occassionally overflow. When | |
69 | this happens, the board must be reset to avoid a lockup problem in early | |
70 | revision 8390's. Resetting the board will cause all of the data in the ring- | |
71 | buffer to be lost - requiring it to be re-transmitted/received...slowing things | |
72 | even further. Because of these problems, maximum throughput on boards of this | |
73 | type is only about 400-600k per second. The 16bit boards, however, have 16k of | |
74 | memory as well as much faster memory access speed. Typical memory access speed | |
75 | on these boards is about 1.7-4MB/second (with the Novell NE2000 being the | |
76 | slowest and the SMC 8013 being the fastest). These boards generally have no | |
77 | problems keeping up with full ethernet speed. The only problem I've seen with | |
78 | these boards is related to the (slow) performance of the BSD Net/2 malloc code | |
79 | when additional mbufs must be added to the pool. This can sometimes increase | |
80 | the total time to remove a packet enough for a ring-buffer overflow to occur. | |
81 | This tends to be highly transient, and quite rare on fast machines. I've only | |
82 | seen this problem when doing tests with large amounts of UDP traffic without | |
83 | any acknowledgments (uni-directional). Again, this has been very rare. | |
84 | ||
85 | All of the above tests were done using a 486DX2/66, 486DX/33, 386DX/40, | |
86 | 8-9Mhz ISA bus, using FreeBSD 1.0. TCP tests were done with the 'ttcp' | |
87 | performance test utility, and also with FTP client/server. UDP tests were done | |
88 | with a modified version of ttcp (to work around a bug in the BSD Net/2 UDP | |
89 | code related to queue depth), and also with NFS. | |
90 | ||
91 | KERNEL INSTALLATION | |
92 | ------------------- | |
93 | (Note that this driver comes standard in FreeBSD 1.0, NetBSD 0.9, and 386BSD | |
94 | 0.2, and therefore doesn't require installation) | |
95 | To 'install' this driver, the files if_ed.c and if_edreg.h must be copied | |
96 | into the i386/isa kernel source directory and the following line must be | |
97 | added into the file i386/conf/files.i386: | |
98 | ||
99 | i386/isa/if_ed.c optional ed device-driver | |
100 | ||
101 | To build a kernel that includes this driver, first comment out any 'we', | |
102 | 'ec', or 'ne' devices in your kernel config file. Then, add a line similar to | |
103 | the following (modify to match your cards configuration): | |
104 | ||
105 | device ed0 at isa? port 0x300 net irq 10 iomem 0xcc000 vector edintr | |
106 | ||
107 | Note that the 'iosiz' option is not needed because the driver automatically | |
108 | figures this out. However, if you have problems with this, it can be specified | |
109 | to force the use of the size you specify. | |
110 | The iomem 0xcc000 option is not need for NE1000/NE2000 boards because they | |
111 | use programmed I/O rather than shared memory to access the NIC's memory. | |
112 | On 3Com boards, the tranceiver must be enabled in software (there is no | |
113 | hardware default). In this driver, this is controlled using the "LLC0" link- | |
114 | level control flag. The default for this flag can be set in your kernel config | |
115 | file by specifying 'flags 0x01' in the 'ed' device specification line (this | |
116 | is necessary for diskless support). Otherwise, the tranceiver is easily enabled | |
117 | and disabled with a command like "ifconfig ed0 -llc0" to enable the tranceiver | |
118 | or "ifconfig ed0 llc0" to disable it; this assumes that you have the modified | |
119 | ifconfig(8) that originally appeared in the 386BSD patchkit. To specify the | |
120 | 'flags' option, use a line similar to: | |
121 | ||
122 | device ed0 at isa? port 0x300 net irq 10 flags 0x01 iomem 0xcc000 vector edintr | |
123 | ||
124 | Flags can be similarly specified to force 8 or 16bit mode, and disabling | |
125 | the use of transmitter double buffering. The various supported flag values | |
126 | are: | |
127 | ||
128 | Disable tranceiver 0x01 | |
129 | Force 8 bit mode 0x02 | |
130 | Force 16 bit mode 0x04 | |
131 | Disable multi TX buffering 0x08 | |
132 | ||
133 | To use multiple flags, simply add the values together. Note that these | |
134 | numbers are in hexadecimal. If the 'Force 8 bit' and 'Force 16 bit' flags are | |
135 | both specified, the 8 bit flag has precedence. | |
136 | The use of the above flags should only be necessary under exceptional | |
137 | conditions where the probe routine incorrectly determines the board type (such | |
138 | is the case with Compex boards, which require the 16bit flag and an iosiz | |
139 | 16384), or where the high performance of the transmitter causes problems with | |
140 | other vendors hardware. | |
141 | ||
142 | ||
143 | KNOWN PROBLEMS | |
144 | -------------- | |
145 | ||
146 | 1) Early revision DS8390B chips have problems. They lock-up whenever the | |
147 | receive ring-buffer overflows. They occassionally switch the byte order | |
148 | of the length field in the packet ring header (several different causes | |
149 | of this related to an off-by-one byte alignment) - resulting in "NIC | |
150 | memory corrupt - invalid length NNNNN" messages. The board is reset | |
151 | whenever these problems occur, but otherwise there is no problem with | |
152 | recovering from these conditions. | |
153 | 2) 16bit boards that use shared memory can conflict with 8bit BIOSes, BIOS | |
154 | extensions (like the VGA), and 8bit devices with shared memory (again | |
155 | like the VGA, or perhaps a second ethernet board). There is a work- | |
156 | around for this in the driver, however. The problem is that the | |
157 | ethernet board stays in 16bit mode, asserting its '16bit' signal on | |
158 | the ISA bus. This signal is shared by other devices/ROMs in the same | |
159 | 128K memory segment as the ethernet card - causing the CPU to read the | |
160 | 8bit ROMs as if they were 16bit wide. The work-around involves setting | |
161 | the host access to the shared memory to 16bits only when the memory is | |
162 | actually accessed, and setting it back to 8bit mode all other times. | |
163 | Without this work-around, the machine will hang whenever a reboot is | |
164 | attempted. This work-around also allows the board to co-exist with | |
165 | other 8bit devices that have shared memory. This has only been | |
166 | implemented for SMC/WD boards, but I haven't seen this problem with | |
167 | 3Com boards (i.e. if you have a 3Com board, you might experiance the | |
168 | above problem - I haven't specifically tested for it). | |
169 | 3) The NIC memory access to 3Com and Novell boards is much slower than it is on | |
170 | SMC boards; it's less than 1MB on 8bit boards and less than 2MB/second | |
171 | on the 16bit boards. This can lead to ring-buffer overruns resulting in | |
172 | additional lost data during heavy network traffic. | |
173 | ||
174 | $Id: ed.relnotes,v 1.4 1993/11/22 11:15:16 davidg Exp $ |