Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!linus!philabs!cmcl2!seismo!brl-tgr!tgr!ART@ACC.ARPA From: ART@ACC.ARPA (Art Berggreen) Newsgroups: net.unix-wizards Subject: IBM DACU Message-ID: <1073@brl-tgr.ARPA> Date: Wed, 28-Aug-85 15:51:44 EDT Article-I.D.: brl-tgr.1073 Posted: Wed Aug 28 15:51:44 1985 Date-Received: Thu, 29-Aug-85 08:39:51 EDT Sender: news@brl-tgr.ARPA Lines: 62 This probably doesn't belong in unix-wizards, but the original note was, and I can't think of another newsgroup except maybe tcp-ip. Also it may be of interest to someone running one the IBM unix ports. > > You need the following hardware: > > IBM Device Access Control Unit (DACU), which provides DEC UNIBUS > slots and connects to an IBM block multiplexer channel. > > IBM PC w/128Kb and 1 floppy, which is the brains of the DACU > > 1 Interlan UNIBUS dumb Ethernet card, plus cables, tranceivers, etc. > > Incidentally, the IBM mainframe does all the protocol processing; > the DACU and Interlan cards are unintelligent and the PC is just there > to get the DACU started; the packets don't pass through the PC. > Supposedly this all works OK, but I haven't used it. Contact your IBM > rep for further info. If you get the product announcment info for the program, > all the basic questions are answered there. Having had some experience getting one of our boards running on a DACU, I thought that I'd add my observations. The DACU is essentially an IBM PC with two special I/O devices, an interface to IBM 370 channels and a UNIBUS interface. The channel interface emulates a graphics controller on the IBM channel and the UNIBUS interface emulates the CPU end of a UNIBUS. Both controllers are DMA into the PC's memory. The PC is responsible for initiating I/O transfers through both controllers and handling interrupts from both. While the DACU does look like more or less like a real UNIBUS it does have some strange "features". When the PC wants to access UNIBUS device registers it must turn off the logic which grants UNIBUS devices NPR (DMA) control of the UNIBUS, suspending DMA activity while device registers are manipulated. Device register access itself is indirect. When the PC wants to access a device register, the address and data are placed in DACU registers and the PC waits for the controller to perform the device register access on the UNIBUS. Therefore DMA latency on the UNIBUS is affected by the code in the PC which controls the UNIBUS device and whether that code can be interrupted with DMA disabled. Another strange thing was that interrupt requests were granted to the UNIBUS device and then when the interrupt vector was asserted on the UNIBUS an interrupt request to the PC is made. This holds the UNIBUS interrupt transaction in mid cycle until the PC gets around to processing the interrupt and reading the vector at which time the UNIBUS interrupt transaction is allowed to terminate. This has two effects, DMA cannot occur because the UNIBUS is held in a transaction and devices which may timeout the interrupt vector transaction could get upset. For a stream of small packets, the PC is definitely could be a bottleneck, depending on the packet handling overhead in the PC. Also, any DMA latency requirements of the device should be looked at acrefully. Finally, if the use is to tie TCP/IP in IBM machines to Ethernet, make sure, that there is ARP code in the mainframe or in the PC. Needless to say, we are taking a different approach to the problem. "Art Berggreen" ------