jgd@uwmcsd1.UUCP (John G Dobnick) (04/17/86)
We are looking for a mechanism to connect 4.2bsd systems currently on an Ethernet to a Sperry 1100. The 4.2bsd systems are no problem. Our specific need is a hardware/software solution to connect the Sperry 1100 system to the Ethernet. The required protocol is TCP/IP, since that is what we use on the 4.2bsd systems that we wish to communicate with. We would like to hear from other sites that have such a configuration [mainframe (of any sort) to Ethernet], preferable by means of an IO channel connection, since our application requires the bandwidth of an IO channel. We know of a few solutions already: There is a channel interface designed by a DoD agency (Naval Ocean Systems Center?) that connects a PDP/11-23 (or some such machine) to an IO channel. An alternative version of this is to connect the PDP/11-xx to a communications port on the Sperry 1100. Both of these configurations use a software package called "fuzzball". There is also one commercial solution that we know of; INTERnet Systems Corporation uses a micro-VAX II to drive an IO channel interface. (These channels, by the way, are "IBM"-type byte channels.) The information we need includes required hardware and software, supplier, availability, approx. cost (if available), mainframe type (mfg. and model, if applicable). We would also like to know if you are actually using this in a test or production mode, and what the data traffic and throughput are. Feel free to include any other information you may think appropriate or useful. We have an INTERnet box on-site, but it is not performing to our expectations. We would *really* like to hear from other INTERnet users! Please! If there is sufficient response, I will summarize to the net. Responses by e-mail preferred. Thank you. -- -- John G Dobnick Computing Services Division @ University of Wisconsin - Milwaukee UUCP: ...ihnp4!uwmcsd1!jgd INTERNET: uwmacc!uwmcsd1!jgd@rsch.wisc.edu
ron@brl-sem.ARPA (Ron Natalie <ron>) (04/21/86)
> We would like to hear from other sites that have such a configuration [mainframe > (of any sort) to Ethernet], preferable by means of an IO channel connection, > since our application requires the bandwidth of an IO channel. The guys down at the University of Maryland who I believe were the first one to do TCP/IP for the UNIVAC were recently talking about using the IBM DACU to connect the Sperry channel to a UNIBUS Ethernet board (Sperry channels are pretty much interchangable with IBM channels). These guys arealso did the software at NOSC.The FUZZBALL plays internet gateway to a serial line to the UNIVAC. Frankly, I believe this is much preferable than kludging a ethernet to the Sperry in any of the methods I've seen so far (DACU's are kind of silly devices). > one commercial solution that we know of; INTERnet Systems Corporation uses a > micro-VAX II to drive an IO channel interface. (These channels, by the way, > are "IBM"-type byte channels.) We are in the middle of having INTERNET systems hook up our Sperry, I'll let you know how it turns out.
louie@umd5.UUCP (Louis Mamakos) (04/23/86)
In article <169@brl-sem.ARPA> ron@brl-sem.ARPA (Ron Natalie <ron>) writes: >> We would like to hear from other sites that have such a configuration [mainframe >> (of any sort) to Ethernet], preferable by means of an IO channel connection, >> since our application requires the bandwidth of an IO channel. > >The guys down at the University of Maryland who I believe were the first >one to do TCP/IP for the UNIVAC were recently talking about using the IBM >DACU to connect the Sperry channel to a UNIBUS Ethernet board (Sperry >channels are pretty much interchangable with IBM channels). These guys >arealso did the software at NOSC.The FUZZBALL plays internet gateway to >a serial line to the UNIVAC. Frankly, I believe this is much preferable >than kludging a ethernet to the Sperry in any of the methods I've seen >so far (DACU's are kind of silly devices). > >> one commercial solution that we know of; INTERnet Systems Corporation uses a >> micro-VAX II to drive an IO channel interface. (These channels, by the way, >> are "IBM"-type byte channels.) > >We are in the middle of having INTERNET systems hook up our Sperry, I'll >let you know how it turns out. Yes, as far as I know, we were the first with TCP/IP on the Sperry. We're currently running a 40KB sync line to a fuzzball which has an ethernet on it. It seem that we've got some users, and they have all this data you see.. and they want to move it REAL fast. So. We are in the process of evaluating the Sparticus (now Fibronics) and Auscom IBM-type-byte-channel ethernet boards, and hope to have one here soon. Well see how fast our purchasing people can deal with this one. -- Louis A. Mamakos WA3YMH University of Maryland, Computer Science Center Internet: louie@trantor.arpa UUCP: {seismo!umcp-cs, ihnp4!rlgvax}!cvl!umd5!louie
root@topaz.RUTGERS.EDU (Charles Root) (04/23/86)
We have a product from ACC which is an Ethernet interface for an IBM mainframe. It is a controller with several processors in it. One of them talks to an IBM channel. Another one talks to the Ethernet. Somewhere in all that hardware is a program that pretends to be an IMP. The idea is that the whole thing taken together looks exactly like an ACC 1822 interface (the hardware you would use to connect an IBM mainframe to the Arpanet). This allows us to use UCLA's TCP/IP implementation for MVS, since it supports IMP's. I kept putting off saying anything about this, in hopes that I would be able to write a more definitive article, with some performance figures and the like. Unfortunately, I have yet to be able to figure out our IBM system well enough to transfer files on it. I have been assured by people who know that our IBM users are using it all the time, and it works. So far I have been losing my battles with ACF2 (the MVS protection system). (This has nothing to do with the ACC box or the TCP software.) The design goal was to have a system that could do very high-speed transfers. It was intended to be an answer to those (including us) who were sceptical of the throughput of a DACU. Eventually I hope to be able to give you actual performance numbers. Actually, their design goals were such that we probably don't have any other systems fast enough to see what it really can do. One other thing: What they are really trying to do is to produce a network front end. The same box, with some slightly different cards, can talk to DDN. They think there is a market for people who would like to talk to both DDN and their own local Ethernet, using the same box. They are also talking about moving parts of the network code into the box, in the long run. I believe they are working with a consulting company that will help you install things and support the UCLA MVS code, though our systems staff seemed to have no trouble getting things up with the code as it comes from UCLA.
louie@umd5.UUCP (Louis Mamakos) (04/24/86)
In article <774@osiris.UUCP> eric@osiris.UUCP (Eric Bergan) writes: >> >We would like to hear from other sites that have such a configuration [mainframe >> >(of any sort) to Ethernet], preferable by means of an IO channel connection, >> >since our application requires the bandwidth of an IO channel. >> >> Yes, as far as I know, we were the first with TCP/IP on the Sperry. We're >> currently running a 40KB sync line to a fuzzball which has an ethernet on it. >> It seem that we've got some users, and they have all this data you see.. and >> they want to move it REAL fast. So. We are in the process of evaluating >> the Sparticus (now Fibronics) and Auscom IBM-type-byte-channel ethernet >> boards, and hope to have one here soon. Well see how fast our purchasing >> people can deal with this one. > > We have an Auscom currently connected to our IBM systems, running >XNS. I believe that our Auscom is a block channel, not a byte channel, >interface, though. The XNS resides in the Auscom itself, and the >virtual circuits look like a series of 327x terminals. This avoids the >protocol load on the host. We have implemented Sun's RPC mechanism in >the IBM, and our IBM is routinely making RPC calls from COBOL to our >Pyramid over all of this. (The Pyramid does database lookups, and >returns the information to the IBM.) We presented a paper on all of >this at the last Uniforum, for those that are interested in more >details. > > We have also looked at the Sparticus equipment. At the time we >were starting, Sparticus only supported VM, not MVS. I understand that >this is currently changing. There is, however, still the issue that >Sparticus runs TCP/IP in the host, and so you still have to pay for the >mainframe cpu cycles to handle the protocol. We would be very >interested in any Sparticus customers that could tell us how much of >their cpu gets chewed up doing the TCP/IP protocols. I remember that >the old UCLA code was estimated at chewing up about a third of a >reasonable sized IBM mainframe, which is far more than we could put up >with. > >-- > > eric > ...!seismo!umcp-cs!aplcen!osiris!eric I guess my terms were a bit incorrect. When I said 'byte' channel I meant an IBM style byte or block mux channel on the Sperry rather then the Sperry 36 bit wide "word" channel. We've been running TCP/IP on the host for quite a while, and found that it doesn't present a high enough load to worry about off-loading the processing to a front end. For our application, we'd prefer not to have an overly clever front end "helping" us, but rather a simple interface to an ethernet that won't bend the existing code too far out of shape. We'll see what happens; usage patterns are likely to change when the higher bandwidth network connection arrives. Who knows what these crazy users will do next! -- Louis A. Mamakos WA3YMH University of Maryland, Computer Science Center Internet: louie@trantor.arpa UUCP: {seismo!umcp-cs, ihnp4!rlgvax}!cvl!umd5!louie
jcollas@ll-xn.ARPA (Juan J. Collas) (04/24/86)
In article <169@brl-sem.ARPA>, ron@brl-sem.ARPA (Ron Natalie <ron>) writes: > > We would like to hear from other sites that have such a configuration > > [mainframe (of any sort) to Ethernet], preferable by means of an IO > > channel connection, since our application requires the bandwidth of > > an IO channel. > > The guys down at the University of Maryland who I believe were the first > one to do TCP/IP for the UNIVAC were recently talking about using the IBM > DACU to connect the Sperry channel to a UNIBUS Ethernet board (Sperry > channels are pretty much interchangable with IBM channels). These guys > arealso did the software at NOSC.The FUZZBALL plays internet gateway to > a serial line to the UNIVAC. Frankly, I believe this is much preferable > than kludging a ethernet to the Sperry in any of the methods I've seen > so far (DACU's are kind of silly devices). I believe Spartacus Computers, Inc. (they're owned by Fibronics) makes a box which is channel attached. It uses the block multiplex channel, and connects to an ethernet transciever directly. Sounds a little more elegant than a DACU to the Ethernet. It's also a *hell* of a lot faster. - Juan Collas, MIT Lincoln Labs -- Juan Collas MIT Lincoln Laboratory