info-vax@ucbvax.ARPA (09/22/84)
From: engvax!KVC@cit-vax
Ok, enough people wanted this that I am blasting it to the whole
mailing list. This is a very preliminary version. We have since
gathered some more information, but the little bit in here could
be valuable enough to the right people that I am not going to
wait for the final paper. We also have a program that reads the
DEUNA counters (undocumented) and prints a monitor-like screen
of them. Kinda handy for watching your traffic, although the
data comes fromsuch a low level that it is very hard to interpret.
I will send out the bigger paper when my co-author (Ned) gets
back from Oklahoma (yuck). If anyone wants the counter-displayer,
I will see what I can do about distributing that too...
------------------------------------------------------------------
DEUNA Programming Considerations
We recently completed adapting an implementation of TCP/IP for a DEC
DEUNA that was originally written for a Interlan NI1010 device. The
code was written in BLISS and operates under VAX/VMS. We thought our
experiences might be of interest to anyone trying to choose proper
network hardware.
Using the Interlan NI1010 and its device driver NIDRIVER is a very
straightforward affair. One person assigns it (exclusively) and
proceeds to read and write packets with simple QIOs (P1 is the packet
address, P2 the packet length). The packets include the Ethernet
header, so the address being sent to is just part of the data being
sent (Question -- the sender address is also part of the packet; can
the user set this to other than his own address in order to "forge" a
packet??). The same stuff applies for receives.
The Interlan has a lot of special functions to run onboard
diagnostics, control the number of UBA map registers used for buffers
and so forth.
The DEUNA and its associated XEDRIVER, by contrast, are much more
complex beasts. The documentation in the I/O User's Guide is some of
the worst we have ever seen -- it is unclear and even out and out
wrong in some places. The following material was determined by much
experimenting and eventually by reading the XEDRIVER source on fiche.
When a channel is assigned to the DEUNA (XEA0) the driver creates a
new UCB (in effect a new device) and hands this newly created entity
back to the caller (XEAn, where n>=1). The result is that many people
may use a single DEUNA all at once for different tasks. Everybody
gets their own unit.
There are restrictions on what the various folks on the DEUNA may do
while they are sharing it, however. The DEUNA only has one Ethernet
address (aside from multicast addresses) available. The first person
that gets the device may set the address. After that, as subsequent
people assign channels, they are denied permission ("bad parameter")
to set the receive address. You have to be the exclusive user to set
that address.
Now, everyone uses the same device address, so the DEUNA uses the
Ethernet protocol word (a field in every packet) to pick who gets
what. This can be done in one of three ways. The first person to use
a given protocol gets to pick how the protocol may be used by others:
(1) Exclusive use. This protocol is reserved for the current user.
Anyone else who tries to use it gets a "bad parameter" error.
This is the default when someone starts to use a given protocol
unless otherwise specified.
(2) Default user. Anyone may use this protocol to transmit, but only
the default user (the first one to use this protocol) gets any
receive packets.
(3) Shared use. Each user is required to declare who they are going to
be sending to. Then users are locked in to sending each to their
single specified destination. When a packet is received, the driver
figures out who its from and hands it to whoever is sending to that
particular place. If no one is sending there the thing is thrown
out.
This is all fairly nasty and complicated, but it gets even worse.
There are some special facilities of the Ethernet/DEUNA that have
characteristics of their own:
(1) Promiscious mode. This is a mode where the device receives ALL
packets, not just those addressed to it. The documentation says
that only one unit can have promiscious mode enabled, but we
found it impossible to share the device and have it enabled at all.
(2) Echo mode. This is a setting where the any messages transmitted are
also regarded as received messages. The usual receive rules as to
who gets the packet apply. This can only be used by one unit on a
given DEUNA. If this is turned on you can do wierd things like
activating default user mode and sending a packet to another
user of the device. It is particularly useful for debugging, when
you have no idea what is actually flying around out there.
(3) Loopback mode. This is the same as echo mode except that the message
is never actually sent out on the net. The documentation says you
use the symbols NMA$C_LINCN_NOR and NMA$C_LINCN_LOO to control
this. These symbols do not exist. We found that NMA$C_STATE_ON and
NMA$C_STATE_OFF, which are used with most of the other settings,
seems to work.
(4) Multicasting. Multicasting is an Ethernet "feature" whereby messages
can be sent to more than one receiver simultaneously. Only one unit
can have this active at a time. The multicast addresses (up to 10 of
them) are specified by the user. The list of addresses may be
modified by appends or deletes at any time.
(5) Data chaining. We have no idea what this is. The documentation is
not informative. Any unit can use it or not as its chooses.
The actual QIO's to set all this up are fairly simple. An IO$_STARTUP
is used to initiate activity. This runs the onboard diagnostics,
which take about 6 seconds. The P2 parameter can be used to pass a
list of parameters and settings. This list takes the form of
parameter name, parameter value, parameter name, parameter value, etc
. It is passed by descriptor. Exactly the same list is used with IO$_
SETMODE if something needs to be changed later. However, IO$_
SENSEMODE tries to return the ENTIRE list into a user-supplied buffer
; you don't get to pick what you want. (The documentation implies
that you do.) It always returns things in a specific order and you
only have to give it a long enough buffer to get what you want. The
exact order can either be determined by experiment or by looking at
XEDRIVER source (see the table LINE_PARAM).
The IO$_SENSEMODE function also has an undocumented feature. The
DEUNA maintains a slew of statistics about what is going on on the
Ether. These counters may be read using the function modifier IO$V_RD
_COUNT on the IO$_SENSEMODE call. If IO$V_CLR_COUNT is used the
counters are read and then zeroed. The counters returned are in the
order defined by the hardware starting with the seconds since the
counters were last zeroed. Refer to figure 4-16 (page 4-31) of the
DEUNA User's Guide (NOT the IO User's guide) for a complete list of
all the counters. The counters apply to the whole DEUNA and it looks
as though anybody can read or clear them with impunity.
When transmitting the P5 parameter specifies who the packet is being
sent to; the actual packet data (passed as P1) does not contain the
Ethernet address as it does on the Interlan. Similarly, on receives
the P5 parameter optionally returns who the sender was. If you don't
bother with P5 you will not know who the sender is (unless shared
access mode is used in which case packets from all but one source are
screened out).
One more gotcha:
Due to the potentially large size of Ethernet packets you have to
watch your nonpaged pool carefully when using the DEUNA (especially
when TWO operations are active at the same time). Also, we were
getting SS$_EXQUOTA errors for a while until we bumped the SYSGEN
parameter MAXBUF, which controls the maximum size of an I/O buffer
allocation (EXE$ALLOCBUF). The default is 1300 or so, the max
Ethernet packet is 1500 bytes.
Conclusions:
For our application the DEUNA was the only choice (it was nice to
find this out in retrospect -- we didn't have any say in the hardware
purchase). We are now happily running both DECnet and TCP/IP out of
the same DEUNA. This would not have been possible with an Interlan,
both because it cannot be shared and because DECnet does not support
it. It took us only 4 man-days to get TCP/IP running on the DEUNA,
and we were both programming in a language completely new to us (
BLISS). Also, the fact that the DEUNA can handle even more stuff at
once brings up other possibilites like running BACKUP directly over a
DEUNA protocol circuit. (DECnet seems to run at about 280Kbaud, TCP/IP
at around 140Kbaud. A raw circuit should be much faster.)
Ned Freed (scgvaxd!ymir!mathmgr @ CIT-VAX)
MATHLIB Project
Harvey Mudd College
Claremont, CA. 91711
Kevin Carosso (engvax!kvc @ CIT-VAX)
Hughes Aircraft Co.
(213) 648-1025