dd (02/15/83)
--------------------- Rice University -------------------------------------- Keep in mind that all U-B equipment claiming to run on ethernet is INCOMPATIBLE with Xerox Ethernet above the signal voltage level. Two competing protocols can SHARE the cable but users of U-B stuff can't access, for instance, a line printer using Xerox protocol/hardware! P.S.: Most people don't believe this when they first hear it. Call U-B and they will finally admit it after a few comments about protocol levels ... -------------------- Simon Fraser University ------------------------------- We at SFU Computer Science have had an Ungermann-Bass Net/One baseband system for about a year and a half, now. If we had to do it again, we would probably go to something else, but let me tell you some more and you can decide. We wanted a system to link our various computing resources - terminals, a VAX 750, some micros, peripherals, the usual thing. Net/One works pretty well for that, although there are some problems. We also wanted a system suitable for distributed data base research - concurrent access control and distributed query processing. We haven't had any luck there, for reasons I'll get to. As far as software goes, the virtual circuit stuff is really good. It does its job well, and seems to be pretty well bullet-proof under any kind of reasonable operating conditions. We haven't tested the datagram service, so I can't say anything there. (We just got release 82.10, by the way. It was late, as usual.) The hardware works adequately well. The NIU boards don't seem prone to failure once installed and working, but they have a distressing habit of arriving with a port or two dead. (I can only speak for the 4S2P and SIXPAC boards, those are all we've used so far.) Be sure to check the boards and get replacements while they are still under warranty. As far as service for hardware bugs from UB, our experience has been, basically, forget it. They seem to be up to their ass in alligators and not interested in fixing a particular problem you have. What's worse, they emphatically will not tell you enough to diagnose and fix the problem yourself. We have had continuing trouble with our NSM, and have currently replaced the Winchester, the Winchester controller board, the floppy controller board, a relay which controls the floppy drive motor, and the fan. We have also had consistent software problems here, including inability to access the floppy after booting from the Winchester, and vice-versa, and a recent discovery that U-B's disk format program cannot handle formatting the Winchester. U-B evidently knew about this but went ahead and released the software anyhow, since the formatter from a previous release could handle it. Our main complaint has been in trying to get U-B to live up to agreements they made at the time we entered into the initial purchase agreement. After inspecting the system, we came to the conclusion that we could only do the distributed data base research if we could alter some of U-B's low level net software. They agreed to provide us with this info, we signed and paid, and they have been stonewalling ever since. My advice to you, therefore, is that if you enter into any kind of agreement outside of straight sale, and if you have any thoughts of getting more information out of them later, get it in writing and witnessed before you sign for the system. A few random thoughts. The limit of six virtual circuits per board is due to buffer space limitations. If they tell you there is a way around it, we'd sure like to know. Our experience is that they are consistently behind in software development (behind their salesmen, that is ; when they finally do get something out, it will probably be quite good if it relates to net data transport, and full of holes otherwise). The apparent reason for the stonewalling about additional info is that U-B was badly burned by an OEM that they had released source to. I gather the lawsuit is still going on, but I don't off hand now who the guilty party is. (Would like to, though, if you happen to find out.) As you can see, I have strong opinions on the subject. Feel free to give me a call. I'd be interested to know your final decision, and why.
jdd (02/16/83)
From unm-ivax!dd Tue Feb 15 09:26:28 1983 In-Real-Life: DD Subject: U-B survey, second installment... (unm-ivax.136) Newsgroups: net.lan ---------------- Rice University --------------------------------- Keep in mind that all U-B equipment claiming to run on ethernet is INCOMPATIBLE with Xerox Ethernet above the signal voltage level. Two competing protocols can SHARE the cable but users of U-B stuff can't access, for instance, a line printer using Xerox protocol/hardware! P.S.: Most people don't believe this when they first hear it. Call U-B and they will finally admit it after a few comments about protocol levels ... The Ethernet spec covers a great deal more than signal levels (for example, bit-rate, bit-encoding, bit-synchronization, bit-ordering, byte-ordering, basic packet format, addressing, minimum and maximum packet sizes, packet spacing, CRC, error detection and handling, and so forth and so on). I doubt that U-B equipment is incompatible with these. However, there are also higher-level protocols where systems can diverge. For example, a VAX talking only TCP-IP cannot communicate with a Xerox Print Server talking only PUP (say), even if each uses the same Ethernet for transport. The trick here is the word "only". It makes some sense for something as dumb as a print server to have a single higher-level protocol (handling such things as virtual circuits, flow control, error control, as well as features specific to printing) built into it. These would not be changable as a user option, but you could twiddle your other machines to talk the right way to funny peripherals. On the other hand, the VAX can be expected to be more flexible. I agree that it seems inexcusable for an Ethernet controller for a general-purpose machine, such as a VAX, not to allow access to the raw net (possibly in addition to providing certain higher-level protocols for efficiency). Cheers, John DeTreville Bell Labs, Murray Hill
neil (02/18/83)
#R:unm-ivax:-13600:hplabs:6300001:000:1023 hplabs!neil Feb 18 14:54:00 1983 The Ungermann-Bass Net/1 stuff really CANNOT talk to anything else other than U-B boxes (at least the current stuff. They have prommised to change it...) The reason is that they have the U-B Ethernet address hard coded into their firmware, so U-B boxes can only address other U-B boxes. Also, the standard Net/1 firmware give no raw access to an Ethernet datagram packet; they only allow U-B type datagrams (that talk about U-B board numbers, and connectors on a board, etc.) Clearly U-B wants to sell you an ENTIRE system. I suspect that they will be changing this. I have heard that they have gotten a bit bloodied in the market because people wanted to talk to more than terminals. On the plus side, if you use Net/1 for what it was designed for (terminal multiplexing to computers; printer multiplexing, etc) then it does quite nicely. But if you want computer-computer datagrams (especially to things made by other vendors) be sure they have revised their firmware. Neil Katin HP Labs ucbvax!hplabs!neil