HEDRICK@RUTGERS.ARPA (07/23/84)
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA> Various people have asked what we think of the Pyramid, so it seems worth to respond in public. Please note that I am neither a Unix wizard nor a hardware expert, so don't expect any deep insights from me. I speak mostly as a user and system manager. Also, during the summer we are preparing for an onslaught of students in Sept, but we have not loaded down the system yet. So if there are problems that only show up under heavy load, we haven't seen them yet. Note that the following review is almost totally qualitative. We haven't done much in the way of benchmarking. I am tired of tests that show a 6502 to be twice the power of an IBM 3081. All I care about is the performance under a heavy timesharing load. I have never seen any way to evaluate that other than to put a heavy timesharing load on it. We haven't done that. When we do, I'll tell you how it works. We are relying on various tests done at other places that suggest that it should do noticably better than a 780. I have made no commitments that depend upon its being twice a 780, though there is some evidence that it is. So far the hardware has been solid. We have had the machine for 3 to 4 months, and have not had a hardware failure. For those who don't know it, the Pyramid is a proprietary processor, i.e. not a 68000, 8086, etc. I don't know how it is built. Surely it must use bit-slices, PLA's, etc., because there isn't enough board space to do what they have done using old technology. In a single low-boy cabinet we have a processor, 4 Mbytes of memory, a Fujitsu Eagle, a Cipher Cachetape 800/1600 bpi tape drive (one of the small horizontal drives), two multibuses (one for the disk and tape, and a separate one for the Ethernet), an Interlan Ethernet controller, 2 "intelligent terminal processors" (one per 16 terminal lines), some number (probably 1) of 68000-based peripheral controllers (for the disk and tape), and a 68000-based console processor. The console is a Wyse terminal. It's amazing to see a single box that contains the equivalent of a VAX 782, an RUA81, and a TU80. Detailed comments: - the processor is inspired by the RISC machine research. It has a large number of registers (48 are accessible to a user program at any one time), the special features to make procedure calls fast, etc. But it has a few more instructions than a real RISC machine. They look sort of vaguely like a VAX (or a 68000, etc.), in that there are two operands, and they can be register, memory, indexed, etc. But fewer addressing modes than on a VAX, and certainly fewer instructions. - the console looks sort of like an IBM system, in the sense that has multiple "screens", which let you look at various pieces of information about the inside of the system. One of the screens makes the console into a normal terminal. I have no trouble using it as a terminal, though some of our student operators seem to find ways to hang the system when doing that. Presumably they put it into modes where they don't belong. It don't happen to like the console terminal itself, mostly because of the keyboard. I don't like its touch, and it has control and escape in frustratingly odd positions. On the other hand, we don't choose a computer on the basis of its console terminal. - people who are serious about tape will, of course, specify a real tape drive instead of the Cipher thing. On the other hand, it has worked fine for us. DUMP does not quite drive it at full speed, but we don't find dumps slow enough to be a problem. Some people have expressed qualms about the self-loading feature of the Cipher, but it has never failed to self-load for me. It takes a long time to load, but if I am patient, it does. (I wish I could say as much for the TU77.) Currently we are doing weekly full saves and incremental saves every few days. We are also using tapes for getting software on and off. However the amount of tape operation during the semester will be considerably heavier. We will be interested to see how well the Cipher holds up. - disk transfer speed is currently limited by its use of the multibus. Pyramid is working on a controller that will go into their own high-speed bus. This should give better performance. That is sort of meaningless, since I don't have any way to say what the current performance is. As I said, this is not a quantitative review. Now let's talk about the software. Pyramid's claim to fame is that they have implemented real 4.2bsd and real System V. None of this "system X with system Y enhancements". It's quite simple: they support both sets of system calls (using different numbers for 4.2 and System V). The code to support both is there in the kernel. The base kernel is 4.2, but they have taken enough code from System V to support all the System V facilities. This means that you have virtual memory and the Berkeley improvement to disk handling even if you are using a System V program. The choice of systems is determined primarily by which set of files you use. I won't go into how you choose this, but effectively you can ask for either the 4.2 /bin or the System V /bin, and of course that controls which set of software you get. Your C programs become 4.2 or V primarily by which library they are linked with, since the actual system calls are in the library routines. (By cleverness, it is possible to build programs that use both. Login does that.) All the facilities are present that you would expect: using one "universe" by default, or selecting which one you want in various ways. There is nothing particularly magical in the way this is all done, but it does work smoothly, and it lets us use software taken from other Universities or presumably (if we ever saw anything that we wanted) from people who like System V. (I shouldn't be so snide - if we get a system for general University-wide purposes, we will surely want to put S on it.) Now the obvious question is, does the software work? The answer is release-dependent: OSX 2.1 [we won't talk about earlier versions]: C worked, the common utilities worked, many of the less common options and utilities didn't work. Fortran had lots of problems. (I won't swear that this was an officially released version of Fortran, however.) SDB's single-step command crashed the micrcode. OSX 2.2 [the current version, although 2.3 is about to come out]: many fixes. It mostly works, but there are still a few significant holes. [One of the most unfortunate is that there are problems with most of the obvious ways of doing backups. Even the one that seems to work is completely safe only if you take the system standalone and do fsck first. If you don't, it may miss files.] We got our big Fortran program to work. The only Fortran problem we now see is that SDB [the debugger] can't access its variables in a Fortran program. (This will be critical in a student enviornment.) I have some reason to think that the Fortran optimizer may not work. TCP has some problems, because the Pyramid sometimes sends the wrong checksum. We didn't have any crashes under 2.2 (but recall that we also don't have much in the way of load). We had some hangs, but they seem to have been due to people doing odd things to the console. OSX 2.3 [which will be out shortly] should be in fairly good shape. I have reason to think that all of the problems we have seen are fixed in this release. (I admit to being sceptical about the TCP checksums, however. When any piece of code has to be fixed more than once, I am sceptical about all fixes.) They have even fixed one thing that one might not think they could fix: the open-line problem. (This is the problem that every system I have seen has: if you have a long terminal line that isn't connected to a terminal, Tops-10, Tops-20, and Unix all tend to see spurious login attempts or other junk, and waste lots of CPU time handling that line. They have done some magic things in the kernel and init to get rid of this problem.) The thing to notice is that these releases have come about 2 months apart. That is fairly fast progress. I certainly don't expect any organization to have totally bug-free software. What I do want is a good way of getting problems fixed. The folks at Pyramid are by far the most helpful and responsive software organization I have ever seen. Their local software people know what they are doing. When we need help from Corporate, they have an 800 number that gets us to the appropriate people. It will be interesting to see whether they continue this way as they grow. What they don't have is the official DEC SPR process. We don't fill out forms in quadruplicate, and we don't get any acknowlegement of what has happened to our report. Personally, I am happy to trade this off for fast and knowlegable support. I have reason to believe that the adminstrative overhead at DEC in tracking SPR's and writing responses is large compared to the effort of actually doing the fixes. As long as the release cycle is 2 months, it is unnecessary to respond to bug reports individually. For those who are wondering about other languages, Pascal and Lisp will soon be out. We have seen both running, but they are not quite ready for release. (For those of you who know the Berkeley design aids, Lyra works.) These are all of the languages that we use, so I don't know much about the other typical Unix languages. There is a Snobol, but I have never tried it. We have advised them to try to find a way to get APL and Ada. They have a group that has been very active in getting third-party software people to port software. Most of it is things that we don't need, so I haven't followed this very much. There is no question that at the moment you can find more software under VMS. But they seem to be collecting software quickly. Unless problems show up under heavy load that we haven't seen, we think that the software we need to do computer science courses will work by Sept 1. Significant development work will continue for the rest of this fall, as they move away from the PCC code generator to their new, super-duper optimizing code generator (which should be used for all of their "conventional" languages [i.e. probably not for Lisp]). So far they seem to be willing to adjust priorities to fit the needs of particular customers. Overall I am quite enthusiastic about both the product and the company. We have not seen much in the way of kludgery. They seem to be doing things the right way. However, if you buy one you should understand the differences (both good and bad) between buying a machine that has been running for less than a year and one that has been around for years, and has a large software base. You should also be willing to tolerate Unix (unless we can get them to implement a third Universe: Tops-20). I think what is going to make or break them in the long run is: - can they come up with something that outperforms the Venus as well a their current product outperforms the 780? (Or do they need to? Maybe a cheap machine that is 2x a 780 is good enough, particularly if they have multi-processor configurations.) - can they build up a large set of software? - can they continue to provide good software support as their customer base grows? My nightmare is that I will wake up one morning and find this letter: "Now that our software has stabilized, we are going to begin our new Software Support Strategy. In order to improve our ability to track your problems, we will supply you with Software Reliability Report forms, in quintuplicate, on 8.5 by 13 inch paper. All communications with our software support staff will be by means of these forms. Fixes to any problems will show up in the next release of OSx, which will be coordinated with ATT's official release of System VII." -------