Path: utzoo!utgpu!attcan!uunet!lll-winken!ames!nrl-cmf!ukma!rutgers!att!feathers!djh
From: djh@feathers.ATT.COM (5450)
Newsgroups: comp.dcom.lans
Subject: Re: LANCE vs. Intel (was Token Ring (was: Re: Info on LANs))
Summary: Intel 82586: great power == great responsibility
Message-ID: <84@feathers.ATT.COM>
Date: 6 Jan 89 14:11:22 GMT
References: <12786@cup.portal.com> <920001@hposdl.HP.COM> <10777@s.ms.uky.edu> <11060@ulysses.homer.nj.att.com> <11065@ulysses.homer.nj.att.com>
Reply-To: djh@feathers.ATT.COM (Dan Hansen--615-5450)
Organization: AT&T Bell Labs, Red Hill, NJ
Lines: 25


The Intel 82586 allows the programmer to scatter a frame (for
transmission or reception) in non-contiguous buffers.  In addition
the number of bytes in each buffer is chosen by the programmer.
This flexibility is why the 82586 is THE most powerful LAN controller
on the market (sez me).  Unfortunately this flexibility can cause
poor performance if the programmer is not careful with his choices.

From my reading of Van Jacobson's data, this is probably the case in
his experiment.  The fact that the host CPU is not 100% active is not
significant.  The host CPU was probably idle during most of the wire
time (1.2ms for a 1518 byte frame).  The poor performance was probably
caused by excessive processing prior to transmission and after reception
of frames (the wire would be idle during this time).  Remember the amount
of chip related processing is largely dependent on how the programmer
lays out the structures for frames.

I have programmed a variety of other LAN controllers (SEEQ, 8390, 82588)
so I am familiar with different vendor's approaches.  The 82586 can
closely match or surpass the performance of any chip I have seen.  I
have written drivers that transmit and receive data at 9.5Mb/s using the
82586 in 10MHz 80286 based PCs.


Dan Hansen