stevens@hsi.UUCP (03/30/87)
Given the choice of a DEC DELUA or a Micom/Interlan N1010A for a
VAX 8600, which Ethernet interface would you choose ? They both
seem similar in price and bus requirements. We already have
an N1010A on a 785 and a DEC DEQNA on a MicroVAX.
Also, will the DEUNA driver supplied with 4.3 BSD work with
the DELUA ?
Richard Stevens
Health Systems International, New Haven, CT
ihnp4 ! hsi ! stevenstomlin@hc.UUCP (04/01/87)
in article <552@hsi.UUCP>, stevens@hsi.UUCP (Richard Stevens) says: > Also, will the DEUNA driver supplied with 4.3 BSD work with > the DELUA ? The DEUNA driver from 4.3bsd has problems driving DELUAs. It is, however, possible to get the machine up by typing "BOOT ANY" (on a 780, what is it B/3 on a 750?, etc.) and waiting a couple seconds before giving the kernel "hp(0,0)vmunix" (or whatever is the path to your kernel). The problem is that it takes quite some time before the DELUA is ready to accept commands after a UNIBUS RESET (which starts the DELUA off running diagnostics) and the 4.3 driver doesn't wait for the DELUA and consequently hangs is a busy loop. A "hack" is a large DELAY before heading into the probe code which will get things running, but here is a "fix" from Donn Seeley (donn@utah-cs.arpa): Subject: Problems using DEUNA driver for DELUA interface +FIX Index: sys/vaxif/if_de.c 4.3BSD Description: We have 5 VAXen, ranging from 750s to an 8600, running 4.3 BSD using DELUA network interfaces. Lou Salkind's DEUNA driver works with the DELUA, but there are problems (see below). The first problem, and the one which took us the most time to understand and 'fix', was that 5 of the 12 DELUA boards shipped to us were broken. Of course the first two we tried were in the broken set and we had a very difficult time trying to figure out what was going on. The VMS diagnostic was not very useful, since it failed on all the boards. After talking to DEC, we found that it was 'normal' for the boards to fail one of the tests in the diagnostic (EVDYB test 3), and the boards which failed on other tests turned out to be precisely the boards which failed under Unix. In case someone else runs into this problem, the symptoms when running under Unix were that the board would run for a while and then wedge, refusing to interrupt or do anything else useful. The threshold varied from board to board -- one would croak after exchanging only a couple packets, another after a couple hundred. The other problem, the one we can actually fix, is that the DELUA takes up to 15 seconds to run through self-test after a bus init, and this can cause the DEUNA driver to screw up during autoconfiguration. (See below). Repeat-By: When 4.3 BSD is booted on systems whose consoles run at 1200 baud or higher, it's easy to reach the probe routine for the DEUNA/DELUA before the board has finished self-test. If this occurs, the board wedges and the autoconfiguration can hang. Fix: I changed the driver to wait up to 15 seconds for self-test to finish; the changes are presented below. (I also made changes to print out the device type in the attach routine and to be more careful about the interupt enable / command interlock 'feature' -- if a write to csr0 changes the interrupt enable bit, any changes to the command field are ignored). The principal changes are in deprobe() and deattach() in if_de.c: ---------------------------------------------------------------- *** /tmp/,RCSt1026392 Tue Jul 15 21:28:21 1986 --- if_de.c Thu Jul 10 21:09:02 1986 *************** *** 123,128 **** --- 123,144 ---- i = 0; derint(i); deintr(i); #endif + /* + * Make sure self-test is finished before we screw with the board. + * Self-test on a DELUA can take 15 seconds (argh). + */ + for (i = 0; + i < 160 && + (addr->pcsr0 & PCSR0_FATI) == 0 && + (addr->pcsr1 & PCSR1_STMASK) == STAT_RESET; + ++i) + DELAY(100000); + if ((addr->pcsr0 & PCSR0_FATI) != 0 || + (addr->pcsr1 & PCSR1_STMASK) != STAT_READY) + return(0); + + addr->pcsr0 = 0; + DELAY(100); addr->pcsr0 = PCSR0_RSET; while ((addr->pcsr0 & PCSR0_INTR) == 0) ; *************** *** 146,151 **** --- 162,168 ---- register struct de_softc *ds = &de_softc[ui->ui_unit]; register struct ifnet *ifp = &ds->ds_if; register struct dedevice *addr = (struct dedevice *)ui->ui_addr; + int csr1; ifp->if_unit = ui->ui_unit; ifp->if_name = "de"; *************** *** 153,161 **** --- 170,193 ---- ifp->if_flags = IFF_BROADCAST; /* + * What kind of a board is this? + * The error bits 4-6 in pcsr1 are a device id as long as + * the high byte is zero. + */ + csr1 = addr->pcsr1; + if (csr1 & 0xff60) + printf("de%d: broken\n", ui->ui_unit); + else if (csr1 & 0x10) + printf("de%d: delua\n", ui->ui_unit); + else + printf("de%d: deuna\n", ui->ui_unit); + + /* * Reset the board and temporarily map * the pcbb buffer onto the Unibus. */ + addr->pcsr0 = 0; /* reset INTE */ + DELAY(100); addr->pcsr0 = PCSR0_RSET; (void)dewait(ui, "reset"); *************** *** 245,250 **** --- 277,284 ---- incaddr = ds->ds_ubaddr + PCBB_OFFSET; addr->pcsr2 = incaddr & 0xffff; addr->pcsr3 = (incaddr >> 16) & 0x3; + addr->pclow = 0; /* reset INTE */ + DELAY(100); addr->pclow = CMD_GETPCBB; (void)dewait(ui, "pcbb"); *************** *** 296,303 **** s = splimp(); ds->ds_rindex = ds->ds_xindex = ds->ds_xfree = ds->ds_nxmit = 0; ds->ds_if.if_flags |= IFF_RUNNING; - destart(unit); /* queue output packets */ addr->pclow = PCSR0_INTE; /* avoid interlock */ ds->ds_flags |= DSF_RUNNING; /* need before de_setaddr */ if (ds->ds_flags & DSF_SETADDR) de_setaddr(ds->ds_addr, unit); --- 330,337 ---- s = splimp(); ds->ds_rindex = ds->ds_xindex = ds->ds_xfree = ds->ds_nxmit = 0; ds->ds_if.if_flags |= IFF_RUNNING; addr->pclow = PCSR0_INTE; /* avoid interlock */ + destart(unit); /* queue output packets */ ds->ds_flags |= DSF_RUNNING; /* need before de_setaddr */ if (ds->ds_flags & DSF_SETADDR) de_setaddr(ds->ds_addr, unit); *************** *** 739,744 **** --- 773,781 ---- case SIOCSIFFLAGS: if ((ifp->if_flags & IFF_UP) == 0 && ds->ds_flags & DSF_RUNNING) { + ((struct dedevice *) + (deinfo[ifp->if_unit]->ui_addr))->pclow = 0; + DELAY(100); ((struct dedevice *) (deinfo[ifp->if_unit]->ui_addr))->pclow = PCSR0_RSET; ds->ds_flags &= ~(DSF_LOCK | DSF_RUNNING); -- Bob Tomlinson -- tomlin@hc.dspo.gov -- (505) 667-8495 Los Alamos National Laboratory -- MEE-10/Data Systems
henry@utzoo.UUCP (Henry Spencer) (04/05/87)
> Given the choice of a DEC DELUA or a Micom/Interlan N1010A for a > VAX 8600, which Ethernet interface would you choose ? ... I don't know anything about the DELUA, but it may well have considerably higher performance than the 1010A. [Brief digression: I assume that a N1010A is the same interface I know as an NI1010A.] I ran an experiment on the 1010A which produced some very unimpressive numbers for its transmit performance. I coded a little standalone code loop that just threw the same packet into the interface over and over, and then timed the result on the cable. (I had an oscilloscope watching the cable for other reasons.) The machine was an 11/44, i.e. slightly faster than a 750, so I doubt that the CPU was a big bottleneck. I plotted packet frequency versus packet length, and got a nice straight line. Sending an N-byte packet via the NI1010A takes 600 + 3.3N microseconds. Note that the time on the cable itself is about 20 + 0.8N, so this is *not* very impressive throughput. I have no specific idea where the 600-us overhead comes from. The extra time per byte is probably at least partly, I'd guess, inefficient Unibus DMA. Smarter DMA and a multi-packet transmit buffer (so that one could be DMAing in from the Unibus while another was being transmitted) could improve things a lot, I suspect. -- "We must choose: the stars or Henry Spencer @ U of Toronto Zoology the dust. Which shall it be?" {allegra,ihnp4,decvax,pyramid}!utzoo!henry
msd@nrcvax.UUCP (Marc Dye) (05/15/87)
<><><>
One piece of information that may or may not be helpful:
The Interlan controller (NI1010A) operates at an
extremely degraded rate (like about 1/6th!) if not
using it's ROM-based Ethernet address.
This is not usually an issue when Network Layer to Link Layer
address mapping is performed by something like ARP (normal TCP/IP
fare these days), but has caused trouble in multiple controller
installations of XNS protocols, for example, where the host address
is the same for all link layer interfaces and the mapping from
XNS to Ethernet addresses is trivial.
Marc S. Dye: USENET -> ihnp4!nrcvax!msd
seismo!utah-cs!utah-gr!uplherc!nrc-ut!nrcvax!msd
ARPANET -> utah-cs!utah-gr!uplherc!nrc-ut!nrcvax!msd@SEISMO.CSS.GOV
+----------------------------------------------------------------------+
| For every action, there is an equal and opposite government program. |
+----------------------------------------------------------------------+terryl@tekcrl.UUCP (05/16/87)
In article <916@nrcvax.UUCP> msd@minnie.UUCP (Marc S. Dye) writes: ><><><> > >One piece of information that may or may not be helpful: > > The Interlan controller (NI1010A) operates at an > extremely degraded rate (like about 1/6th!) if not > using it's ROM-based Ethernet address. I didn't see the original article that made this claim, so I can only ask a couple of questions: The NM-10 has two sets of commands: load physical address/set physical address to default, and set/clear insert source address mode. The load physical address address command DISABLES the NM-10's physical address recognition hardware, forcing the NM-10's processor to dismiss packets whose physical address does not match that loaded by the load physical address command(as quoted from an addendum to the NM-10 user's manual), so I can see where there might be some speed degradation. The other two commands, set/clear insert source address mode, controls whether the hardware or software provides the physical address as the source address of transmitted frames (again, as quoted from the addendum). The manual mentions that "substantial improvement in transmitting performance results while the NM-10 is in this mode" (clear insert source address, i.e. it must be provided by the software). So my question is this: which one are you talking about when you say "the NM-10 operates at an extremely degraded rate...."? >This is not usually an issue when Network Layer to Link Layer >address mapping is performed by something like ARP (normal TCP/IP >fare these days), but has caused trouble in multiple controller >installations of XNS protocols, for example, where the host address >is the same for all link layer interfaces and the mapping from >XNS to Ethernet addresses is trivial. I'm not sure what you mean by this. Are you talking about multiple ethernet cards on one machine???
chris@mimsy.UUCP (05/16/87)
>In article <916@nrcvax.UUCP> msd@minnie.UUCP (Marc S. Dye), talking about the slower operation of the N1010A when it does address comparison and insertion in software, writes: >>This is not usually an issue when Network Layer to Link Layer >>address mapping is performed by something like ARP (normal TCP/IP >>fare these days), but has caused trouble in multiple controller >>installations of XNS protocols .... In article <1645@tekcrl.TEK.COM> terryl@tekcrl.TEK.COM writes: > I'm not sure what you mean by this. Are you talking about multiple >ethernet cards on one machine??? He is. The Xerox network concept of an address is quite different from that in TCP/IP. There are no classes; all addresses are a six byte object that looks (surprise!) just like an Ethernet address. In the Xerox scheme, this address is (at least conceptually) wired into the CPU backplane, rather than being present on each Ethernet board. The thing that distinguishes between multiple boards on a single machine is the `network number', a four byte object. Any machine with more than one board can act as a packet router between its two or more networks, but it must have the same Ethernet address on each cable. There is code in 4.3BSD to set the Ethernet address of the DEUNA or the N1010A, for those who use the kernel XNS protocol and must do this sort of thing. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris