Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!altos!altos86!dtynan From: dtynan@altos86.Altos.COM (Dermot Tynan) Newsgroups: comp.unix.i386 Subject: Re: Altos 5000 (somewhat long; sorry) Message-ID: <3893@altos86.Altos.COM> Date: 31 Aug 90 01:09:04 GMT References: <1990Aug16.174514.2646@NCoast.ORG> <15759@bfmny0.BFM.COM> <1990Aug22.171700.23382@ico.isc.com> Organization: Altos Computer Systems, San Jose, CA Lines: 143 In article <1990Aug22.171700.23382@ico.isc.com>, rcd@ico.isc.com (Dick Dunn) writes: > This is nonsense. "Supporting" a user is very much more than allowing a > terminal to be plugged in. Quite simply put, it doesn't matter whether you > can handle the I/O connections or even the I/O bandwidth; you don't have > the CPU power to support 200 people actually *using* the system. In actual fact, the APS5000 supports a *connectivity* of 512 terminals. We support 200 users doing "real work". Naturally, the definition of real work varies from case to case, but we tested the machine with 200 simulated users (another machine provides the input), all doing database accesses, and similar Real World(tm) tasks. The machine performed quite well. It was able to access, update, and change entries a lot faster than I could read or comprehend the data. Certainly, trying to do 200 kernel makes would be slow, but that isn't a Real World situation. Engineering isn't about designing for absolute worst-case, it is about making tradeoffs, in this case between cost and overall performance. Considering that the overwhelming majority of our customers (and most everyone elses - the net is very myopic, when it comes to defining what Real People(tm) do with their machines) need that kind of performance, and don't need to be able to sustain 200 kernel makes, it would be wrong of us to overdesign the machine. But, to say that it doesn't support 200 users, when you probably haven't used the machine, much less tried loading it down, is a best, an injustice. One of the biggest problems in getting the machine to support that number of users, was in the operating system itself. I went to an SVnet meeting once, where someone from Amdahl was bitching to AT&T about the fact that PIDs were only 15 bits. Amdahl machines can have more than 32000 processes running at a time, which makes PIDs somewhat useless. SCO is more guilty of this than AT&T. Time and again, the standard code assumes (somewhat fairly, for a run-of-the-mill PC) that there would *never* be more than oh, eight serial lines. You put 512 on there, and a lot of algorithms that don't mind traversing a linked-list of eight devices need to be rewritten. This is what makes the Altos OS that bit better. I'm not saying that ISC has this kind of myopia, but don't think that you can take an operating system primarily designed (in this case) to run on a PC, which usually has 2 serial ports, and expect to get it to run 512 ports, 200 users with any kind of efficiency, unless the people who did the port were thinking of this, which SCO certainly weren't. In the general case, one can tell that all System V development at AT&T (or UI, or whatever they call themselves today) is done on individual workstations, and development at Berkeley is done on one single overloaded VAX780. BSD gives up on paging, after a certain threshold, and drops down to pure swapping. SYSV does nothing of the sort. A sure indicator that the people at Berkeley were trying to squeeze the last drop out of a heavily loaded machine, whereas the people at AT&T didn't care, because their machines never go beyond (hand-waving) 50% utilization. Which OS would *you* rather put on a heavily loaded machine (everything else being equal). Don't get me wrong, trying to produce a generic OS that is all things to all machines is a tough challenge, and in that respect, we have it a *lot* easier here at Altos. We can put the effort into tuning the OS for our hardware platform, and if you don't think that can produce some significant results, you need to look a little closer at some of the high-end machines of this industry. > On terminal boards - it's good that you've got some intelligence out on the > boards, since interrupt handling is one of the weak points of the 386/486, > but that's really nothing particularly unusual. (Even my modem's got a > 68000 in it.) You are of course, talking about the Telebit trailblazer, which is to my mind, one of the best modems on the market. However, it doesn't offload the CPU one damn bit, unless you are trying to emulate PEP :) Its one thing to put "some intelligence out on the boards", but its another to actually use it wisely. I was just recently looking at the Specialix board, and it seems to be the first board on the market which addresses the whole issue of serial I/O wisely (Altos products notwithstanding :). For the most part, serial add-on boards for the PC assume that the world is DOS-shaped, and that the UNIX community is this weird group in California, who haven't left the sixties. Certainly everyone at ISC must be painfully aware of this. Each and every eight-port serial card is identical, until you boot UNIX... While (desperately) trying to remain within the realms of objectivity, Altos has a long-standing tradition of offloading the main CPU, and getting several I/O processors to do the dirty work, leaving the CPU to do more productive things. A lot of effort went into designing host interfaces which don't burden the *or* the I/O processor. This has all been added to the 5000, along with some painful lessons... > > ...With the largest currently supported SCSI disk at 1GB > > per disk, the System 5000 can have up to 30GB of total disk space... > > Total expansion capacity is a useful number to look at to be sure it's not > too small, but mostly it's a red herring. Again, you're going to run out > of CPU power long before you run out of disk, if your users are doing > anything serious. This *really* depends on what you are doing. There is a version of this machine that is designed to be used as a NFS or RFS file-server. Then, who cares about CPU power. The 486 can handle a *lot* more disk requests, than the disks can. Then it boils down to sheer volume. Furthermore, the more disks you stripe across, the better the disk performance. > Disk striping is truly useful, but disk mirroring is mostly a pawn in the > feature game. It takes substantially more I/O bandwidth to do the double > output, and it doubles the cost of disk storage. Why not spend only a few > bucks extra and buy reliable disks? Again it depends on what you are trying to do. Ask Ti about /usr3 on our main development machine. He and I both spend a couple of days trying to recover lost source. That wouldn't have happened had we been mirroring the drive. Bottom line. On the "reliable disks" question, I think that should be referred to comp.risks, or comp.arch. If you do actually find a "reliable disk", I'll buy one off you. That is, of course, if you can make it for less than $10^6. > > You see, when we built the System 5000 we aimed very high. This > > system is so capable that we position it as a mini-computer, among > > the ranks of Pyramids and Sequents... > > People are using standard 386 and 486 machines as mini-computers, like it > or not. No-one says you can't use my old Commodore calculator as a mini-computer. For certain (limited) functions, it is as fast as anything produced by DEC. For a personal computer to be called a minicomputer (really, this debate also belongs in comp.arch, which periodically tries to define what a mini- computer is), it should support a lot of users. The only way to get a single-processor i486 to support a lot (like, maybe 200 :) users, is to offload as much of the work as possible. That we did. > Let's get down to some real numbers here. We ought to look at the price: > performance in quantitative terms, not glowing generalities. I'm not > saying you're wrong; I'm saying you haven't told us anything on this > point. What's your benchmark for price/performance? Probably if you took the 5000 and used standard single-user benchmarks, it would compare evenly with any 486 PC clone. However, load it up with a lot of users, doing a varied mix of CPU-intensive and I/O intensive work, and the 5000 would break away from the pack. How do I know this? Because we've done it. The figures are publically available. The SystemPro got left at the starting gate. It with eight disks, the 5000 with 2! > What I see, overall, is that you've got a fairly capable, quite expandable > 486 EISA machine. I don't see anything qualitatively different about it. Maybe you should buy one, and try it out :) - Der -- Dermot Tynan, Altos Computer Systems, San Jose, CA 95134 dtynan@altos86.Altos.COM (408) 432-6200 x4237 "Five to one, baby, one in five. No-one here gets out alive."