Return to BSD News archive
Newsgroups: comp.unix.bsd.freebsd.misc
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!pandora.devetir.qld.gov.au!netpak
From: netpak@devetir.qld.gov.au (Paul Koch)
Subject: Re: Linux network code vs. FreeBSD
Nntp-Posting-Host: orion.devetir.qld.gov.au
References: <489b0t$65q@future.internexus.net> <48u4t8$qvr@buffnet2.buffnet.net> <49ga27$g3i@tempis.quanta.com> <49k85b$q51@vanbc.wimsey.com> <49n0ma$38v@hudson.lm.com>
Sender: news@devetir.qld.gov.au (Network News)
Organization: DEVETIR, QLD, AUSTRALIA
Date: Tue, 12 Dec 1995 00:14:14 GMT
X-Newsreader: NN version 6.5.0 #1 (NOV)
Message-ID: <netpak.818727254@pandora>
Lines: 110
peterb@psc.edu (Peter Berger) writes:
>In article <49k85b$q51@vanbc.wimsey.com>,
>John Henders <jhenders@vanbc.wimsey.com> wrote:
>>rsww@quanta.com (Ross S. W. Walker) writes:
>>>What net interface are you using. If the answer is the 3com 3c509/3c579
>>>then there is you're broken frames. The buffers on these cards are too
>>>small for the performance of the network layer.
>>
>>That's an odd statement. We use a 3c509 on a BSDI box which is running a
>>web server that get 500 hits a minute during peak hours, including one
>>customer's virtual site that serves up samples of his cdrom gif
>>collection, and have never seen this behaviour.
>Agreed. The 3c509 is one of the best ISA ethernet cards available,
>and shines under BSDI. I have one in my FreeBSD box, but haven't hooked
>it up to a LAN yet :-}.
>What he probably meant to say was "FreeBSD's 3c509 driver is buggy."
>(according to the release notes).
I totally agree that the 509 card is a problem. The 509 card has a very
small amount of packet buffering which causes a lot of problems to
networking people.
The following is an extract of a doc I was writing:
There are two types of ethernet cards being used in PCs. One
has high speed packet buffer and the other doesn't. Ethernet
cards with buffer memory will be mapped into the spare 160K
memory space. You will usually find 16K of static ram on these
types of cards. The CPU will read and write packets directly
to the ram on the ethernet card and pass commands to the
ethernet controller via the IO port channel. The following is
a typical event of data through an ethernet card with packet
buffer memory:-
Receiving packets: The ethernet controller will detect packets
destined for itself and save the packet in the receive packet
buffer of the card. The ethernet controller then raises an
interrupt to the CPU to inform it of the received packet. The
CPU communicates to the ethernet controller via the IO port.
Then, the CPU does a simple read of the packet by just reading
the packet straight from the shared memory of the ethernet card.
Transmit Packets: The CPU writes a packet into the transmit
buffer of the ethernet card. The CPU then sends command to the
ethernet controller via the IO port. Status information is also
read via the IO port.
The following is a typical event of the data through an ethernet
card with NO packet buffer memory:-
Receive packets: The ethernet controller will detect the
beginning a packet destined for itself. The ethernet controller
does not wait until the entire packet has been received before
raising an interrupt, but instead it raises an interrupt
immediately. The CPU MUST respond as soon as possible. Since the
ethernet card does not have any buffer space mapped into main
memory, the entire packet has to be read via the IO port. Once
a packet has been started to be received, the CPU must VERY
regularly read the bytes in via the IO port (ie. poll the port
for more data).
Transmit packets: The CPU starts to send the packet to the
ethernet controller via the IO port. When the ethernet controller
gets the beginning of the packet, it immediately starts to
transmit the packet onto the ethernet cable. The CPU MUST very
regularly write the data to the IO port for the ethernet
controller to transmit. If the CPU does not keep up, the card
will under-run on transmit, causing bad packets to be put onto
the ethernet.
So, what is the reason of using an ethernet card which has no
on board packet buffer space. Marketing brouchers suggest that
because the packet doesn't get buffered in the ethernet card,
it will be much fast to transmit a packet than an ethernet card
which has to buffer the packet first. Hhmm! Well unfortunately
this is only a fact when working in a perfect world. The down
side of ethernet cards with no packet buffering is that if the
CPU is interrupted to do something else while it is transmitting
or receiving a packet (ie. disk read/writes on IDE drives or
other IO devices) then the ethernet card will under-run on
transmits and over-run on receives, thus corrupting the ethernet
packets. This is more of a problem on DOS machines because of
its poor interrupt handling.
For packets that get corrupted on receiving, the device that
transmitted the packet will have to retransmit the packet again.
For packets that are corrupt on transmission, this is has a much
worse impact. The packet will show up on the ethernet as a
corrupt packet. A typical result would be that if intelligent
secure ethernet hubs were being used that provided partitioning
of illegal devices, the PC would be partitioned. I have seen
this a lot in practice and it is annoying. It makes it hard
for networking people to find out how an ethernet is running
if bad packets are being transmitted from supposely good
ethernet cards. But then, most PC people who buy these types
of ethernet cards usually don't have any idea that this happens,
or just don't care!
Cards like the 509 card were built for the mass Novell client
market, not to be used in superior operating systems like FreeBSD.
I did some testing between SMC and 509 cards on my two FreeBSD boxes
and found the 509 card would reset at high levels of traffic where
the SMC card had no problem.
Paul Koch
(Why do PC/Unix/Applications people always blame the network before
checking there own systems first!)