LEVYAL@usc-isi@sri-unix.UUCP (09/01/83)
IBM has a Device Attachment Control Unit that sits on the channel and has a UNIBUS port on the output. Is anyone aware of any UNIX work being done to support it? I plan to be doing Ethernet on a 750 , right now the canidate I plan to use is the Network Technologies Fusion system -Any comments? Thanks, Allan
ART@ACC.ARPA (Art Berggreen) (08/28/85)
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"<Art@ACC.ARPA> ------
root%bostonu.csnet@CSNET-RELAY.ARPA (BostonU SysMgr) (08/29/85)
(Re: DACU for IBM mainframe TCP/ethernet etc.) >... >For a stream of small packets, the PC is definitely could be a bottleneck, ^^^^^^^^^^^^^^^^^^^^^^ >depending on the packet handling overhead in the PC... > > "Art Berggreen"<Art@ACC.ARPA> I dunno folks, I say he's waffling :-) -Barry Shein, Boston University P.S. We are using the DACU on ethernet here at BU on our 3081, transfer rates seem analagous to UNIX::UNIX transfers and are likely limited by the remote end (eg. VAX.) That is, tranfer rates using FTP on a clear day will oscillate around 20KBytes/second (as reported by FTP), obviously oscillating wildly for very small files. If someone wants me to run a few experiments through it send me a script and I'll send you the results. I agree this DACU/WISCNET thing is not the last word by any means in IBM/TCP and I encourage Art's group and would be very interested in what they develop but you can just write a check and wait for delivery, I suspect it will serve many people's needs, you will have to decide that for yourself, your mileage may vary.
jqj@cornell.UUCP (J Q Johnson) (08/31/85)
In article <1108@brl-tgr.ARPA> root%bostonu.csnet@CSNET-RELAY.ARPA writes: >P.S. We are using the DACU on ethernet here at BU on our 3081, transfer >rates seem analagous to UNIX::UNIX transfers and are likely limited by the >remote end (eg. VAX.) That is, tranfer rates using FTP on a clear day will >oscillate around 20KBytes/second (as reported by FTP) If you are getting only 20KB/sec. VAX<=>VAX then your tcp needs tuning. A reasonable throughput level is twice that or better (I just tried transfering vmunix from one 780 to another, each with 3com ifs, and got 41KB/sec with loads of 1.8 and 1.4). On the other hand, we are seeing somewhat worse ftp rates through the DACU on our 3081; seems like we need help from Barry with tuning. Another point on the DACU is that the Wiscnet software has extremely high cpu overhead, particularly for lots of small packets (e.g. multiple telnet connections, though presumably tn3270-style interactions involve larger packets). I don't have any statistics off hand, but would be interested in any that other DACU users might have. How much of a 3081 gets burned running 40 active telnet connections, for example?