Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 (Tek) 9/26/83; site hammer.UUCP Path: utzoo!watmath!clyde!burl!mgnetp!ihnp4!zehntel!tektronix!orca!hammer!steveg From: steveg@hammer.UUCP (Steve Glaser) Newsgroups: net.lan,net.unix-wizards Subject: Re: Help! Ethernet configuration Message-ID: <843@hammer.UUCP> Date: Sat, 28-Jul-84 13:05:06 EDT Article-I.D.: hammer.843 Posted: Sat Jul 28 13:05:06 1984 Date-Received: Mon, 30-Jul-84 00:03:36 EDT References: <179@tellab3.UUCP> <867@trwrba.UUCP> Organization: Tektronix, Wilsonville OR Lines: 36 I seem to recall the CHAOSNET people telling us that the interlan boards belong at the very last unibus vector. I'm still not sure why you would want to give them the lowest position in the priority scheme... seems to me they should go at the second to the highest position, just after your uda50's, and other big-time cards. Possibly this will help? Come on now. Vector assignment has absolutely nothing to do with priority. DMA priority is strictly determined by bus position. The only thing that matters on vector assignment is that they not be overlapping. [At least on 4.1 and 4.2 where they probe the unibus space during boot causing interrupts to figure out what's where.] Thus, the only reason for configuring vectors following any particular scheme is that it makes it easier to run other systems which aren't as bright about finding things (say VMS and/or diagnostics). As for the rationale for putting the Interlans at the end of the bus, that's easy. Ethernet protocols already deal with lost/damaged packets by retransmitting so if you get a data late on a recieve, you can safely ignore the packet. Actually on the Interlan card, I don't think you'll ever get these - you just may miss a few NEW packets due to buffer space limits on the card. We have a number of large machines (mostly 780s, some 750s) with lots of Interlan cards, terminal interfaces (DZ and VMZ), tape drives, etc. We even had to hack the tm11 driver to deal with more than 4 tape drives and the dmf32 (aka VMZ) driver to not waste interrupt vector space. Steve Glaser, Tektronix steveg.tektronix@csnet-relay.csnet CSNET/ARPANET tektronix!steveg UUCP