Question about Netgear PNIC card

[Douglas Eadline]

On Tue, 27 Apr 1999, Ramkumar Vadivelu wrote:

> Hi all,
> Is the performance of NetGear's PNIC based cards
> comparable to that of NetGear's 21140 based cards?
> Does someone have any performance number with these 2
> cards?
> 
> I want this information to decide whether I could
> safely migrate to PNIC NetGear based cards...
In case you just joined the list (from  Josip Loncaric):

Becker's tulip.c:v0.90q runs the FA310TX with the Lite-On chipset almost
as fast as a genuine DEC tulip version.  Our netperf results (fast
ethernet, full duplex) are as follows:

DEC tulip:   94.5 Mbit/s        NetGear FA310TX Rev.C1
Lite-On:     90.5 Mbit/s        NetGear FA310TX Rev.D1

We fixed the remaining problems with the Lite-On versions by adding a 2
microsecond delay (using udelay(2)) after setting up the tx_ring entry
but just before triggering an immediate transmit demand.  The reason why
this and only this udelay(2) works are still unclear, but my suspicion
is that under some rare circumstances the immediate transmit demand can
overtake(*) the tx_ring update posting to RAM, so that the network card
reads a partially updated tx_ring entry and gets confused.  If I
understood Becker correctly, the reason why DEC tulip chipset does not
require udelay(2) is that there is an onboard timer which can trigger an
automatic recovery.  Lite-On chips apparently do not do this, so once
you confuse them, they cannot recover by themselves.

By the way, tulip.c:v0.91 came out on 4/14/99.  I have not tried it yet,
but it does not use the udelay(2) fix which we find is essential for
reliable operation.

Sincerely,
Josip

P.S.  We informed NetGear about the problem and the udelay(2) fix, but
so far they have not provided us with an explanation nor an alternative
workaround.  BTW, the fix came from this mailing list, not from
NetGear.  If we did not have the Linux source code and a community of
Beowulf users, we'd still be stuck with NetGear's "support" which is way
behind in resolving problems with their product...

Footnotes:
(*) We use Asus P2B motherboards with 440BX chipset, PC100 ECC RAM, and
Pentium II 400 MHz processors.  A simple "write to memory" gets very
complicated because there is much buffering between the CPU and actual
RAM.  Even though I/O instructions are supposed to flush the write
buffer first, there is still a question of timing within the 440BX
chipset which actually performs the write.  The "write to memory"
depends on a lot of timing parameters, but perhaps the most interesting
is "DWTC--DRAM Write Thermal Throttling Control Register".  As it turns
out, the number of writes within a time window is counted; if a
threshold is exceeded, throttling begins.  During throttling, a limit is
imposed on the number of writes.  If this process is triggered by our
applications, this might explain the rare problems we see.

-- 
Dr. Josip Loncaric, Senior Staff Scientist        mailto:josip@icase.edu
ICASE, Mail Stop 132C                       http://www.icase.edu/~josip/
NASA Langley Research Center             mailto:j.loncaric@larc.nasa.gov
Hampton, VA 23681-2199, USA    Tel. +1 757 864-2192  Fax +1 757 864-6134


> 
> Thanks in advance.
> 
> Ramkumar
> --
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 

-------------------------------------------------------------------
Paralogic, Inc.           |     PEAK     |      Voice:+610.861.6960
115 Research Drive        |   PARALLEL   |        Fax:+610.861.8247
Bethlehem, PA 18017 USA   |  PERFORMANCE |    http://www.plogic.com
-------------------------------------------------------------------