Thanks to:
Joe Fletcher <joe_at_meng.ucl.ac.uk>
Dr. Tom Blinn <tpb_at_doctor.zk3.dec.com>
Basically, the 3000/300 series uses a Lance chip based ethernet controller.
It would take significant effort to find the exact machine specifications
because the TURBOChannel bus architecture is ancient and outdated. Dr. Tom
Blinn provided some very useful information that should help track down the
problem that mostlikely exists in software.
Thanks!
My original messages and their responses are listed below:
>This isn't a Digital UNIX specific question, but this list is the only place
>I know of where it may get answeredd:
>
>Does anyone know if the onboard NIC on the DEC 3000/300 systems has
>any sort of cache or buffer? If so, how much?
>
>I searched the DEC 3000/300 Hardware Reference Guide with no success, and
>Digital's web site doesn't seem to list anything about these systems.
---------------------
From: "Dr. Tom Blinn, 603-884-0646" <tpb_at_doctor.zk3.dec.com>
I checked with a colleague who has done driver development for the "Lance"
Ethernet interface chip used for the on-board Ethernet in the 3000/300.
This is, of course, not all the technical details, but basically, the way
the 3000/300 is implemented, there is private memory associated with the
Ethernet interface, and the interface chip itself (the "lance" chip) does
DMA to or from the private memory. The driver is responsible for taking
input from the private memory into system memory (mbufs, basically), and
for moving outbound data from system memory to the private buffers.
The 3000/300 is the slowest TURBOchannel Alpha system ever made. Even if
the Ethernet chip gets the data off the wire (which it will do provided it
has a buffer in the private memory to hold the data), the kernel driver may
not be able to keep ahead of the data on the wire. This is especially so if
you are doing a lot of other I/O activity, notably graphics, since graphics
on the 3000/300 is really messy (and on-board). And if you put the "lance"
in promiscuous mode, you can almost certainly exceed the data rates that the
rest of the system is capable of attaining.
I don't know of any problems with transmission -- but I can imagine that if
you aren't doing everything right in the software layers, you might manage
to lose data on output. If you don't interface correctly to the hardware,
you could, I suspect, re-use a private buffer before it was free, and that
would lose output data. But if you're going through our driver, I don't know
of any bug that would allow that to happen (but I can't promise you there is
no bug).
I concur that the most likely problem is in the software layers.
Tom
---------------------
Joe Fletcher <joe_at_meng.ucl.ac.uk>
I'm afraid I can't provide much in the way of tech details other than to
suggest you run a search for DEC LANCE which is the name these adapters go
under. I believe they have some buffering, possibly 64K. You might also try
looking for part number PMAD-BA. What I can sya is that in terms of
performance they will quite happily saturate an ethernet if pushed.
---------------------
--
Eric Gatenby -=- raptor_at_mailhub.com -=- egatenby_at_mailhub.com
http://www.netaxs.com/~raptor/ -=- PGP: Web page or key server
#include <netinet/disclaimer.h> /* Standard Internet disclaimer */
Received on Tue Jun 29 1999 - 13:33:20 NZST