ti@altos86.Altos.COM (Ti Kan) (08/22/90)
In article <1990Aug19.214500.18612@pegasus.com> richard@pegasus.com (Richard Foulk) writes: >>Not my idea, unfortunately. The machine in question is an Altos 5000; it runs >>SCO Unix, but *not* the stock version: it has drivers for MultiDrop and Altos' >>serial port concentrators (based on past experience with Altos, they should be >>far more reliable than the norm for PC-class machines), the High Performance >>File Processor (optional attachment), built-in Ethernet controller and SCSI >>controller, etc. I *wish* I could just pick up 386/ix for it! > >I sounds like the Altos hardware has enough strikes against it to condemn >its selection, just like SCO Unix on the software side. > >Remember, popularity is important when selecting hardware and software. >Isn't that why most of us here have selected the 386-ATbus platform? It >keeps the cost down and the alternatives up. > >Richard Foulk richard@pegasus.com Well Richard, popularity can certainly be a consideration since it relates to compatibility. On the other hand, when you think 386-ATbus boxes you are still thinking "Personal Computer". There is nothing personal about Altos' System 5000, despite its EISA bus, i486 CPU, and general PC-like architecture. We chose to go with this hardware architecture *not* to build yet another PC-clone, but to build a truly high-performance multi-user system, while taking advantage of the wide availability of add-on hardware and software available for this platform. Perhaps I am going to sound like I am plugging our systems, but I feel that I have to explain the rationale behind some of our "non-standard" value-added hardware and software feature, so perhaps you'll see why the available "standard" just won't do for our intended application. Our Altos 5000 supports 200 users. What serial port card out there with a "standard" SCO driver can support such a requirement? I bet you won't find any. Thus, we developed the Multidrop card and the associated device driver, allowing connectivity of up to 512 RS232 serial devices (up to 4 multidrop cards, with 128 ports each). This is accomplished via a single cable in the back of the computer per multidrop card, and daisy-chained terminal-cluster units (TCUs) serving 8 RS232 ports per TCU. On our TCU/2 model, there are even 2 parallel ports so printers can be conveniently connected remotely from the computer. Moreover, with an on-board 286 processor and an aggregate throughput of over 70,000 characters per second it out-performs just about any serial card out there. For applications that does not require as many ports that the multidrop provides, we also offer our "Serial concentrator" board that supports 8 RS232 serial ports. This one differs from other such cards in that it has its own 186 processor on board, offloading the main CPU and offers very high performance (try running all ports at 19200 or even 38400 baud on your brand X serial board and see if any of your terminals will drop characters, ours won't). We chose to integrate many functions onto a single "Base I/O card" card, which is shipped with every System 5000. This card has a floppy controller, a SCSI hard disk controller, two RS232 serial ports (corresponding to COM1 and COM2 for compatibility), a parallel port (again, corresponds to LPT1 for compatibility), and an ethernet port. This card takes up only one slot, yet provides all the basic functionality we feel are essential in a true multi-user system. The other slots are hence open for other expansion boards. Ethernet is standard on every system because we feel that this system is ideal as a network file server, while concurrently supporting X display terminals and PCs. For large setups that supports a lot of users, we offer the High Performance File Processor board, which is another SCSI controller board. Up to two such boards can coexist in the system, and in conjunction with the SCSI channel on the Base I/O board, provides a total of 5 SCSI channels, which means up to 35 SCSI devices maximum. With the largest currently supported SCSI disk at 1GB per disk, the System 5000 can have up to 30GB of total disk space (mounted in expansion cabinets, which plug into the back of the computer), and still have space for various other SCSI devices, such as high capacity cartridge tape drive (525MB per cartridge), or the Exabyte 8mm tape drive (2GB+ per tape). Again, what other SCSI controller with a "standard" SCO driver can support this kind of expandability? The Multidrop, Serial Concentrator, Base I/O, and HPFP boards are all 32-bit EISA cards, taking advantage of the increased performance of EISA. To further improve disk performance and reliability, we offer disk striping and disk mirroring. The parallel seeks of disk striping decrease average seek time and the redundancy of disk mirroring provides a measure of data security that is quite necessary in a large system. This, again, is unavailable in a "standard" SCO system (or for that matter, in any other UNIXs that run on a PC). 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. Yet we priced it reasonably, that it is in the same league as the "PCs", such as Compaq Systempro and the HP Vectra. What we offer in addition to the performance and expandability is compatibility. The PC-architecture simply allows us to provide an unprecedented integration of a large UNIX system with all the applications that SCO UNIX supports, as well as DOS compatibility. You can still buy off-the-shelf PC/AT/EISA cards and plug them into the 5000. Our SCO-compatible UNIX guarantees that any SCO- supported applications will simply plug-n-play. I think the Altos 5000 differs from other such 486 EISA boxes (which includes the Compaq and HP mentioned above, as well as a zillion other clones), precesely because we designed it, software and hardware, from the ground up to be a non-PC. See the review of the System 5000 in the July issue of _UNIX WORLD_. I think you'll see why our software and hardware should not be "condemned from selection" because of our efforts to make a PC-like machine perform like a mini. Comments are welcome. -Ti -- Ti Kan \\\ vorsprung durch technik! \\\ Internet: ti@altos.com /// \\\ UUCP: ...!{sun|sco|pyramid|amdahl|uunet}!altos!ti ////////\
rcd@ico.isc.com (Dick Dunn) (08/23/90)
ti@altos86.Altos.COM (Ti Kan) responds to a flame-ette from Foulk about the Altos 5000... > ...On the other hand, when you think 386-ATbus > boxes you are still thinking "Personal Computer"... Not necessarily. We use AT-bus machines for most of our "server" roles, and they work just fine. In fact, with fast disks and a good file system (like ours:-) the performance is quite good. > Perhaps I am going to sound like I am plugging our systems,... [followed by ~ 100 lines of "plugs"] Yes, you do sound that way, but let's just take it as an invitation to a "critical examination" of your claims. > Our Altos 5000 supports 200 users. What serial port card out there > with a "standard" SCO driver can support such a requirement?... 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. 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.) > We chose to integrate many functions onto a single "Base I/O card" > card, which is shipped with every System 5000. This card has a floppy > controller, a SCSI hard disk controller, two RS232 serial ports > (corresponding to COM1 and COM2 for compatibility), a parallel port > (again, corresponds to LPT1 for compatibility), and an ethernet port. Many (most?) *motherboards* nowadays have the floppy, 2 serial, parallel built in. They also have IDE, which is a good "base" disk interface. So you're up a little from that, since you're spending one slot instead of the two (SCSI, net) that a vanilla machine would take. > ...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. > To further improve disk performance and reliability, we offer disk > striping and disk mirroring. The parallel seeks of disk striping > decrease average seek time and the redundancy of disk mirroring > provides a measure of data security that is quite necessary in a > large system... 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? > 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. >...Yet we priced it reasonably, > that it is in the same league as the "PCs", such as Compaq Systempro > and the HP Vectra. 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. > I think the Altos 5000 differs from other such 486 EISA boxes (which > includes the Compaq and HP mentioned above, as well as a zillion other > clones), precesely because we designed it, software and hardware, > from the ground up to be a non-PC. You're waving the term "PC" about like a red flag. What's the real issue? Let's get *beyond* the name game. We often use "PC" to identify the bus structure, or to denote a *86-based machine, but they're used for all sorts of stuff...not just "sitting on a desk, plunking away DOS-like." 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. > See the review of the System 5000 in the July issue of _UNIX WORLD_... _UNIX_World_?? Oh, yeah...isn't that the magazine that just carried an article about UNIX-based BBSes without a single word about either USENET or ARPANET? I think you need a stronger source of review than that. -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...I'm not cynical - just experienced.
shwake@raysnec.UUCP (Ray Shwake) (08/24/90)
rcd@ico.isc.com (Dick Dunn) writes: >_UNIX_World_?? Oh, yeah...isn't that the magazine that just carried an >article about UNIX-based BBSes without a single word about either USENET or >ARPANET? I think you need a stronger source of review than that. It's also the magazine that reviewed SCO's Open Desktop wherein the author (Augie Hansen) claimed "The closest thing to it, in scope, is IBM's OS/2 Extended Edition (EE)". No mention whatsoever of the bundled UNIX offerings from Interactive, Dell, or anyone else. So much for credibility!
ti@altos86.Altos.COM (Ti Kan) (08/25/90)
In article <1990Aug22.171700.23382@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes: >ti@altos86.Altos.COM (Ti Kan) responds to a flame-ette from Foulk about the >> with a "standard" SCO driver can support such a requirement?... > >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. Believe it or not, we have actually tested our System 5000 running 200 users (mixed applications, consisting of Informix database, Uniplex word processor, and various others) via our automated MTS (Multi-user test suite) with really 200 serial connections. While the performance with such a load wasn't exactly speedy, it was possible to connect 200 users to it, and is to some extent quite usable. Obviously, this requires gobs of memory (the current shipping version of the System 5000 supports 64MB maximum), and fast disks systems (not just disk or controller hardware, but highly tuned disk device drivers which we have). We know that more CPU power is necessary for a large system, thus new systems with more CPU power, more memory, and more disk performance is in the works, including multi-processor systems. The point is that we have anticipated a need for high performance I/O subsystems in a large UNIX implementation, and this requires not only speedy hardware, but highly-tuned software designed to squeeze every bit of performance out of them. You are *not* going to get that with any "generic" 386 UNIX products (SCO, Interactive, et. al.) which were designed to run on some "generic" PC hardware. Moreover, companies like SCO and Interactive can't possibly provide the kind of software reliability that we could, given that we has so finely-tuned our software specifically for our hardware platform. In addition to performance tuning, We exhaustively test our software on our hardware platform, and fixed many, many bugs that exists on other 386 UNIX implementations. A vanilla SCO UNIX release and an XYZ PC combination would never pass our strict QA standards. The fact that SCO UNIX-compatible device drivers and application can drop-in shrink wrapped, and other PC-class expansion boards can plug-n-play in an Altos 5000 is simply bonus that you don't get with proprietary hardware/software vendors like Sun, Pyramid, DEC, etc. >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? What do you mean by reliable disks? Any hardware can fail, no matter how well built it is. While tape backups are essential, disk mirroring allows the system to *stay up* in the event one of the mirrored drives fail. This is fault-resiliency that many installations are willing to pay for. I realize that disk mirroring is expensive, but for certain applications it is worth it. Again, the original point of the discussion was the question why one would choose a box like the Altos 5000 with standard EISA bus and 486 CPU, but with special expansion I/O cards and special UNIX release, over a generic PC with SCO or Interactive UNIX. I think I have made my argument pretty clear. -Ti -- Ti Kan \\\ vorsprung durch technik! \\\ Internet: ti@altos.com /// \\\ UUCP: ...!{sun|sco|pyramid|amdahl|uunet}!altos!ti ////////\
palowoda@fiver (Bob Palowoda) (08/25/90)
From article <3854@altos86.Altos.COM>, by ti@altos86.Altos.COM (Ti Kan): > In article <1990Aug22.171700.23382@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes: >>ti@altos86.Altos.COM (Ti Kan) responds to a flame-ette from Foulk about the >>> with a "standard" SCO driver can support such a requirement?... > designed to run on some "generic" PC hardware. Moreover, companies > like SCO and Interactive can't possibly provide the kind of software > reliability that we could, given that we has so finely-tuned our > software specifically for our hardware platform. Oh brother now I have heard it all. Now lets hear some detailed facts on how Altos fined tune there hardware software that makes it more reliable than ISC's or SCO's UNIX (includeing the third party vendors). > performance tuning, We exhaustively test our software on our hardware > platform, and fixed many, many bugs that exists on other 386 UNIX > implementations. A vanilla SCO UNIX release and an XYZ PC combination > would never pass our strict QA standards. FACTS > The fact that SCO UNIX-compatible device drivers and application > can drop-in shrink wrapped, and other PC-class expansion boards > can plug-n-play in an Altos 5000 is simply bonus that you don't > get with proprietary hardware/software vendors like Sun, Pyramid, > DEC, etc. But if they don't pass your strict QA standards what good are they? > Again, the original point of the discussion was the question why > one would choose a box like the Altos 5000 with standard EISA bus > and 486 CPU, but with special expansion I/O cards and special UNIX > release, over a generic PC with SCO or Interactive UNIX. I think > I have made my argument pretty clear. And your ego! -- Bob Palowoda palowoda@fiver | *Home of Fiver BBS* Home {sun}!ys2!fiver!palowoda | 415-623-8809 1200/2400 {pacbell}!indetech!fiver!palowoda | An XBBS System Work {sun,pyramid,decwrl}!megatest!palowoda| 415-623-8806 1200/2400/19.2k TB+
tyager@maxx.UUCP (Tom Yager) (08/25/90)
In article <1990Aug22.171700.23382@ico.isc.com>, rcd@ico.isc.com (Dick Dunn) writes: > ti@altos86.Altos.COM (Ti Kan) responds to a flame-ette from Foulk about the > Altos 5000... > > > Our Altos 5000 supports 200 users. What serial port card out there > > with a "standard" SCO driver can support such a requirement?... > > This is nonsense...you don't have the CPU power to support 200 people > actually *using* the system. Using it for what? Software development? X Window applications? Certainly, 200 users at that level would overwork any 486/25's resources (actually, I can't think of a system for less than about $200,000 that could give 200 CPU-demanding users the performance they WANT, multiprocessing boxes excluded). It's a matter of degrees, however. There are still mid-size and large companies out there serving armies of users from a VAX 780. Data entry, accounting, customer service...most business applications are 90% user interaction. If you can get the data to and from the terminal quickly, then the average user is happy. I have one customer that's still using a 32 user, Z80-based system I installed in '83 or thereabouts. They could afford to move up, heaven knows they've been approached enough times, but they're happy with what they have. > ...you're going to run out of CPU power long before you run out of disk, > if your users are doing anything serious. I guess we have different ideas of the word "serious." I get calls and mail all the time from people who are using 386 UNIX systems to serve ridiculous numbers of users (100 or more). I don't even want to talk about what some people are doing with 286 Xenix. > 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? Even "reliable" disks eventually die. You're running a service business, say, a distribution house. Your order entry, warehouse control, customer service--everything--is on the computer. You've got everything backed up like a good doobie. One of your drives gets smoked. Now, if you're mirrored, your system squawks at you but keeps running. No data lost. If you're not mirrored, your system gets fussed about the sudden inability to communicate with the drive. The data on it, possibly hundreds of transactions since your last backup, is lost forever. Terminals lock, system hangs, customers wait, you lose business. If your data is indispensible, and instant access to it is crucial, then mirroring is worth considering. What's the cost of an extra drive compared to the business and data that can be lost to a system crash? There are a lot of copies of Netware SFT in the hands of businesspeople who agree with me, and a large part of the fuss over the Systempro is for its mirroring and data guarding features. > > 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... That's pretty lofty. I'd say that, if anything puts the 5000 in that class, it is the support for UNIX that the company provides. They offer virtually everything you need to set up a serious multi-user, networked system. Ethernet is standard. Multi-port, multi-drop and Ethernet terminal-server connections are all offered by Altos, with specific support added to the OS by them. Dick, you and I know who to call to get these things separately, and neither of us is put off by the prospect of rooting around in /etc/conf to get things running. Executives have better things to do; they just want stuff that works. Hell, even as a VAR, I'd like to have one number I could call to get everything for my customer. And I would feel better knowing that the company had enough expertise on staff to write some pretty hairy device drivers. The value Altos adds to the OS is significant--it goes farther than just disk drivers. Altos isn't just selling a generic PC with a shrink-wrapped version of UNIX. Not that there's anything wrong with that, but when your needs are defined in dozens of users and gigabytes of disk space, you're definitely better off dealing with a company that has thought these things through in advance. The 5000 is built, hardware and software, for serious (there's that word), commercial use, exclusively for UNIX. > >...Yet we priced it reasonably, > > that it is in the same league as the "PCs", such as Compaq Systempro > > and the HP Vectra. I would place the 5000 in the same class as the Systempro hardware-wise, but Altos' commitment to and support for UNIX is superior. > 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. I worked with one for over a month. I found a lot about the system, the OS, and the company that I felt were "qualitatively different." > > See the review of the System 5000 in the July issue of _UNIX WORLD_... > _UNIX_World_?? Oh, yeah...isn't that the magazine that just carried an > article about UNIX-based BBSes without a single word about either USENET or > ARPANET? I think you need a stronger source of review than that. Thank you for the insult. I can handle criticism as well as any writer, but I am not keen on those who badmouth my work without even having read it. Dick, you and I agree about a lot of things, but on this subject we're obviously at opposite poles. Forgive me, but since I've worked with the system, dealt with Altos, and performed similar research on countless other Intel- based (and other) UNIX systems, I'll humbly consider myself a better authority on the matter than you. In any case, I'm objective: The original posting complained about the 5000's inability to run a certain OS product with which you have a mild involvement. Regardless, I think your swipe at UNIX World, and my review, was out of line. I am generally more diplomatic about disagreements than this, but at 3:15am, I won't spend the time to filter my comments. > -- > Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 > ...I'm not cynical - just experienced. -- +--Tom Yager, Technical Editor, BYTE----Reviewer, UNIX World---------------+ | UUCP: decvax!maxx!tyager NET: maxx!tyager@bytepb.byte.com | | "I just bought...the Macintosh portable. And I took it back. Pain in the | +--butt." --Harry Connick, Jr.-------I speak only for myself.--------------+
rcd@ico.isc.com (Dick Dunn) (08/28/90)
ti@altos86.Altos.COM (Ti Kan) writes, among other hype: | The point is that we have anticipated a need for high performance I/O | subsystems in a large UNIX implementation, and this requires not only | speedy hardware, but highly-tuned software designed to squeeze every | bit of performance out of them. You are *not* going to get that with | any "generic" 386 UNIX products (SCO, Interactive, et. al.) which were | designed to run on some "generic" PC hardware. Moreover, companies | like SCO and Interactive can't possibly provide the kind of software | reliability that we could, given that we has so finely-tuned our | software specifically for our hardware platform... This is an unjustified slam at "SCO, Interactive, et. al." It may be possible to give an unwitting customer this sort of hype, but I don't think it will go over in this newsgroup. There is no factual support provided for the claims, so I think we have to treat them as what they are: clever marketing. Sorry; I won't take that bait, especially since other folks have picked up on some issues of technical substance (like disk mirroring) that belong here. Please advertise elsewhere. -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...I'm not cynical - just experienced.
rcd@ico.isc.com (Dick Dunn) (08/28/90)
tyager@maxx.UUCP (Tom Yager) challenges some of my points about the 5000. At the end, I've got some observations on unintended flames, but first let's take the disk-mirroring ; he hit some shortcomings in my posting... I had said: > > ...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? > > Even "reliable" disks eventually die. True. So do reliable controllers. What I want to get at--and it's something I didn't say at all in my previous posting--is that if you're looking for a certain level of reliability, it's a lot harder than just tossing on extra disks and mirroring. Let's have a look at the overall reliability issues...although I'd remind everyone that fault-tolerant system design is complicated, so we're bound to gloss over things. >You're running a service business, say, a distribution house. Your order entry, > warehouse control, customer service--everything--is on the computer. You've > got everything backed up like a good doobie. One of your drives gets smoked. > Now, if you're mirrored, your system squawks at you but keeps running... OK, this covers one failure mode: a disk dies. There are two questions I think we need to ask: - How likely is this failure mode relative to other failure modes? - Is there another way to get comparable recovery capability? To the second question, I'll suggest "journaling" as providing a lot of what you need, possibly at much less cost. I'm more interested in the first question. I had pointed out that it takes extra I/O bandwidth to handle mirroring; someone responded that if you have the right sort of controller, it will write both disks at once for you. OK, fine, now you've made the controller a single-point-of-failure. I've seen as many motherboard and controller failures as disk failures. I don't pretend my experience is typical, but suppose that it might be. The disks are not the only failure points in the system. Oh, and what about that controller, and the writing: Are you doing read-after-write on both disks to be sure you've got good copies of everything? Are you actually using both disks (always writing both, but reading from whichever is free)? There's a Catch-22 in the failure-mode analysis here: If you're using both disks (to improve performance) you risk having an undetected failure on one disk give you inconsistent data between them...which could quickly make a hash of the data on *both* disks. If you're essentially running on one disk and just writing the other as a backup mirror, you're not getting the ongoing check that you really need for reliability. One of the troublesome aspects of mirroring is that it's just a redundancy at one fairly low level. This is inherently subject to a certain class of error--if there's something just-plain-wrong somewhere, you may end up with nothing more than two wrong copies of your data. It's why I hinted at journaling, because that at least gives you a second copy of the data in a different format, constructed with a different algorithm. (Recovery using a journal takes longer, of course...but it recovers from a different class of problems.) > There are a lot of copies of Netware SFT in the hands of businesspeople who > agree with me, and a large part of the fuss over the Systempro is for its > mirroring and data guarding features. People who can afford extra hardware and software, and who can't afford to be down, will buy solutions that promise greater reliability. That's as it should be. Does the solution make sense? I'm not convinced. I would admonish everyone to bear in mind that being able to sell something is not an inherent indicator of its worth. In this case, I'm not arguing that mirroring is worthless, but I do argue that it's inordinately expensive and only addresses one small part of the overall reliability problem. A single system with mirrored disks on one controller has only one element of redundancy. _ _ _ _ _ Now, let's clean up something about the "insults": > > > See the review of the System 5000 in the July issue of _UNIX WORLD_... > > _UNIX_World_?? Oh, yeah...isn't that the magazine that just carried an > > article about UNIX-based BBSes without a single word about either USENET or > > ARPANET? I think you need a stronger source of review than that. > > Thank you for the insult. I can handle criticism as well as any writer, but I > am not keen on those who badmouth my work without even having read it. Tom: I was *not* criticizing your article. The complete truth of the matter is this: I saw the _UNIX_World_ which contains your article, but what caught my eye first was the BBS article. In my "carefully considered professional (but personal) opinion" the BBS article was so poorly written that it puts the magazine in a bad light. In fact, my comments were directed entirely at _UNIX_World_; at that point I hadn't seen your name on the article. Surely you realize that regardless of how well-researched and well-written your article is, it will be judged in the context of the magazine in which it appears..."birds of a feather" and all that. The BBS article was not the first of its ilk I've seen in _UNIX_World_, either. Having now skimmed quickly through *your* article, I think it's a reason- ably good one--concise, to-the-point. I have some criticisms (primarily the matter of using Neal Nelson benchmarks) but they're specific, and not general dissatisfaction with the article. I've also seen your writing in Byte. I think you're generally reasonably on-target, and in any case you make an obvious effort to get it right. Perhaps you can help _UNIX_World_ improve its reputation within the UNIX community. > ...In any case, I'm objective: The original > posting complained about the 5000's inability to run a certain OS product with > which you have a mild involvement. Come on, come right out and say it. If you think I failed to be objective, point out *where* I failed to be objective. If you think I have some vested interest in whether Interactive's UNIX runs on the Altos 5000, tell me about it. (Honestly, I don't care. They're playing a different game than Interactive is.) > Regardless, I think your swipe at UNIX World, and my review, was out of line. I think your complaint is out of line. I did not take a swipe at your review. I didn't say *anything* about your review. I made a comment about the wisdom of using _UNIX_World_ as a reference. -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...I'm not cynical - just experienced.
ti@altos86.Altos.COM (Ti Kan) (08/28/90)
In article <1990Aug25.014213.17353@fiver> palowoda@fiver (Bob Palowoda) writes: >From article <3854@altos86.Altos.COM>, by ti@altos86.Altos.COM (Ti Kan): >>>ti@altos86.Altos.COM (Ti Kan) responds to a flame-ette from Foulk about the >how Altos fined tune there hardware software that makes it more reliable >than ISC's or SCO's UNIX (includeing the third party vendors). > Without delving into technical details (and possibly divulging proprietary information), all I can say is that being in a team of software engineers working closely with the source code, I cannot imagine how we could have developed our UNIX kernel, device drivers, and utilities to the degree of reliability and performance -- given the time and resources available -- if we didn't have a specific list of target hardware configuration. Granted that SCO and Interactive may have a larger UNIX software development group than we do, but the sheer number and variety of PC-class hardware on the market that they support means that they cannot spare as much development effort into all these nitty gritty optimizations that we could do. In many cases, we as software engineers can have a say in our hardware design specifications, so that the software/hardware integration can be more efficiently implemented. You may not find this significant, but in reality it is an incredible value to be able to simply walk to a different part of the building and talk to the guy that designed a particular expansion board, which you are implementing a device driver for. Moreover, our Software Test and QA team work closely with the engineering team, on our own target hardware, to ensure that everything in various combinations, hardware and software, will work reliably together. To a VAR and a customer who would rather spend their time selling/using a system rather than debugging it, this is also extremely important. >> The fact that SCO UNIX-compatible device drivers and application >> can drop-in shrink wrapped, and other PC-class expansion boards >> can plug-n-play in an Altos 5000 is simply bonus that you don't >> get with proprietary hardware/software vendors like Sun, Pyramid, >> DEC, etc. > > But if they don't pass your strict QA standards what good are they? We obviously can't QA every piece of third party software and hardware packages in house, but we have provided a reliable platform on which not only all basic (and some not-so-basic) functionality have been tested and proven to work, but with fine-tuned performance as an added value. >> Again, the original point of the discussion was the question why >> one would choose a box like the Altos 5000 with standard EISA bus >> and 486 CPU, but with special expansion I/O cards and special UNIX >> release, over a generic PC with SCO or Interactive UNIX. I think >> I have made my argument pretty clear. > > And your ego! I would rather not comment on this, but Tom Yager's follow-up article on this topic eloquently reinforces my point. I am not being ego-centric, I am simply an engineer who is proud of his work and the quality of his company's product. Is there anything wrong with that? -Ti -- Ti Kan \\\ vorsprung durch technik! \\\ Internet: ti@altos.com /// \\\ UUCP: ...!{sun|sco|pyramid|amdahl|uunet}!altos!ti ////////\
palowoda@fiver (Bob Palowoda) (08/28/90)
From article <3864@altos86.Altos.COM>, by ti@altos86.Altos.COM (Ti Kan): > In article <1990Aug25.014213.17353@fiver> palowoda@fiver (Bob Palowoda) writes: >>From article <3854@altos86.Altos.COM>, by ti@altos86.Altos.COM (Ti Kan): >>>>ti@altos86.Altos.COM (Ti Kan) responds to a flame-ette from Foulk about the >>how Altos fined tune there hardware software that makes it more reliable >>than ISC's or SCO's UNIX (includeing the third party vendors). >> > > Without delving into technical details (and possibly divulging proprietary > information), This is what I think alot of customers want to hear. For example they want to know exactly what makes your disk cacheing/mirroring is better and more reliable than lets say DPT's or someone elses. You have to give the customer something to measure the quality of your product against. > degree of reliability and performance -- given the > time and resources available > -- if we didn't have a specific list of > target hardware configuration. So just how are you going to prove to the customers that you spend more time and resources than lets say SCO or ISC. Can you imagine if you found out you spent less time on the QA than they did. Would your product be less reliable if you found out they did? I was wondering why they came out with those lists anyways. Could it be that they run QA suites on that hardware. And before it got on the list it passed the equivalant of Altos test suites. > number and variety of PC-class hardware on the market that they support > means that they cannot spare as much development effort into all these > nitty gritty optimizations that we could do. "nitty gritty optimizations", what you have dirt in your OS? > In many cases, we as > software engineers can have a say in our hardware design specifications, > so that the software/hardware integration can be more efficiently > implemented. Ahh, something interesting. Details? > You may not find this significant, but in reality it is > an incredible value to be able to simply walk to a different part of > the building and talk to the guy that designed a particular expansion > board, which you are implementing a device driver for. Heck I don't spend that much time. I just pick up the phone and call them even if it's another vendor that is out of the building. > Moreover, our > Software Test and QA team work closely with the engineering team, on > our own target hardware, to ensure that everything in various combinations, > hardware and software, will work reliably together. Some of our software and hardware people go to bed with each other. Don't know if this improves reliablity of our product any but at least there working close. [some stuff deleted] >>> Again, the original point of the discussion was the question why >>> one would choose a box like the Altos 5000 with standard EISA bus >>> and 486 CPU, but with special expansion I/O cards and special UNIX >>> release, over a generic PC with SCO or Interactive UNIX. I think >>> I have made my argument pretty clear. >> >> And your ego! > > I would rather not comment on this, but Tom Yager's follow-up > article on this topic eloquently reinforces my point. I am not > being ego-centric, I'm was commenting on Tom's follow-up. > I am simply an engineer who is proud of his work > and the quality of his company's product. Is there anything wrong > with that? This seems to be about the first important thing you said. "his work" and "his company's product". I really didn't mean to sound like I was flameing. It was just a few short comments I got from reading your article. I was actually more interested in the fine technical details that make Altos 486 ESIA bus computers worth 3 or 4 times more than anyone elses. Hey I might even be a potential customer. My company purchases more 100 386's a year and we are looking at 486 ESIA machines for our memory testers. Let's say the Altos machine performs the best. Than he asks me why. What am I going to say "Ti said they spend more time on QA and development than ISC or SCO did on other products". How about Altos has proprietary hardware/software which makes it more reliable. He's going to want comparison measurements to help him determine performance. The term "reliablity" as seen from the customer and manufacturer is too vauge to get into here. One observation I have made is customers measure reliablity against other competeing products internally and this data is usally hard to get a hold of. If Altos 5000 is in a class by itself than I guess there is nothing to compare it against other than the salesperson's word. If it's not considered a PC class machine competeing against other ESIA bus machines, you maybe in the wrong newsgroup. ---Bob -- Bob Palowoda palowoda@fiver | *Home of Fiver BBS* Home {sun}!ys2!fiver!palowoda | 415-623-8809 1200/2400 {pacbell}!indetech!fiver!palowoda | An XBBS System Work {sun,pyramid,decwrl}!megatest!palowoda| 415-623-8806 1200/2400/19.2k TB+
tneff@bfmny0.BFM.COM (Tom Neff) (08/28/90)
I'll say this much in Altos's defense. It can be a major annoyance to run an OS like UNIX on hardware that still, at some fundamental level, thinks it's a desktop PC designed to run Space Invaders. When something weird happens you often have to take it down and boot DOS before you get any meaningful diagnostic answers. When you call vendors you have to have the patience of Job as you peel away layers of half-smart babysitters who keep asking you why you didn't just put a MODE.EXE call in your AUTOEXEC.BAT, or what ROM BIOS routine to call, or what the Norton FAT Zapper says about your files. On the whole if you know you're going to be running UNIX on a box, it's a nice luxury to have the box designed and optimized for the purpose. It's comforting to a certain business mindset to know this is so, as it is to know that one company is behind both hardware and software. The question is, how much more is the luxury worth it. I paid a small premium for an AT&T WGS 6386 network because my experience tells me the one-vendor advantage ends up mattering when your work is important and they pay you to do something besides tinker with your system all the time. But the machines are still PCs and come with diskettes, BIOS documentation etc (and a copy of Windows) despite all the work AT&T has done to make them work as UNIX platforms. I can do things with the video and other hardware under "real" DOS/BIOS control that the UNIX drivers still don't support. Still, paying twice or three times as much for the comfort of knowing my box was developed as a dedicated UNIX super-micro is not worth it to me. Of course, I don't fall in whatever specialized vertical niche it is where you need to support 200 terminals on a single CPU. My guess is that anyone in that niche should shop around for a system that meets those special needs, pay what it costs even it's more than a PS/2 costs, and count himself lucky -- the heck with what the rest of us think. Just make sure that's REALLY what you need... -- "We plan absentee ownership. I'll stick to `o' Tom Neff building ships." -- George Steinbrenner, 1973 o"o tneff@bfmny0.BFM.COM
jackv@turnkey.tcc.com (Jack F. Vogel) (08/28/90)
In article <3864@altos86.Altos.COM> ti@altos86.UUCP (Ti Kan) writes: >Without delving into technical details (and possibly divulging proprietary >information), all I can say is that being in a team of software engineers >working closely with the source code.... GOSH, you "worked closely with the source", how close exactly, 10 feet?? Or was the fileserver right next to your desk :-}. Did you get to touch it at all :-} :-}??! -- Jack F. Vogel jackv@locus.com AIX370 Technical Support - or - Locus Computing Corp. jackv@turnkey.TCC.COM
ti@altos86.Altos.COM (Ti Kan) (08/29/90)
In article <1990Aug28.064145.26246@fiver> palowoda@fiver (Bob Palowoda) writes: > This is what I think alot of customers want to hear. For example they >want to know exactly what makes your disk cacheing/mirroring is better >and more reliable than lets say DPT's or someone elses. You have to >give the customer something to measure the quality of your product >against. Okay, let me be a little more specific. Since Altos UNIX is SCO-compatible, I'll do direct comparisons, and give some examples to back up my comments. I don't know as much about ISC UNIX as I do about SCO's, so I'll refrain from comparing again ISC UNIX. Altos has invested in excess of 250 man years developing the Altos 5000 software and hardware, so I hope those man years weren't for nothing :-). First, let's compare features: 1. SCO UNIX (3.2.2) supports a max of 4 SCSI hard disks on a system. Altos has upped that limit to 30. I think that most will agree that for a large UNIX file server, 4 disks is inadequate. Moreover, On the Altos 5000 the hard disks are controlled via either the Base I/O board (1 SCSI channel) or the HPFP (High performance file processor -- up to 4 SCSI channels). The Base I/O board has a very fast TI SCSI controller chip. The HPFP has an onboard CPU that offloads the main CPU in interrupt handling, as well as possessing intelligence like job combining, etc. This is important as the number of disks is increased. All Altos SCSI disk drivers are optimized via fine-tuned disk request sorting algorithms, scatter/gather I/O, etc. These factors greatly improves disk performance, as can be seen in disk- intensive benchmark results. 2. Altos disk striping and disk mirroring is implemented in the UNIX kernel. SCO has no such support in its UNIX release. Disk striping provides tremendous gains in performance, especially if there are more disks involved. With 4 disks striped on an HPFP board, we observed close to 4x improvement in the disk-intensive Neal Nelson benchmark test 18 running at 60 copies (compared to a single disk). With more disks, the improvement is even more impressive (almost linear wrt the number of disks). As for disk mirroring, in my experience the disk controllers are typically far more reliable than the disk drives themselves. We offer a (relatively inexpensive) way to increase disk reliability (what we call "fault resilience") for those who need it. If you want full fault tolerance, you'll have to pay tremendously more for true fault tolerant systems that the Altos 5000 isn't. 3. Altos UNIX allows you to connect up to 512 RS232 serial devices, via the Altos MDC/2 board and TCU/2 (terminal cluster units). SCO has no such support. Again, high performance serial connectivity is important in a large UNIX installation. Again, the SIO/2 (8-ports) and MDC/2 (up to 512 ports) boards have on board CPUs that greatly reduces the load on the main CPU. Port configuration is handled via Altos' new port configuration utility ("pcu") which allows easy configuration of all serial/parallel ports for terminal/printer/modem in a menu- driven, visual environment. It even displays the correct station- address switch settings of all the TCUs so they can be easily set up. 4. Altos UNIX is optimized for an EISA bus architecture (as opposed to an ISA bus). Since our SIO/2, MDC/2, HPFP, and Base I/O boards are all 32-bit EISA boards, this is an important consideration. There are numerous places in the UNIX kernel where we have made special adjustments to make it run better in an EISA environment (I can't cite specifics). In addition, we provide "uconfig", a utility that is the UNIX back-end of the EISA configuration utility front-end (that comes with EISA systems). The EISA configuration utility configures the hardware so that the sysadmin does not have to worry about hardware resource conflicts (IRQs, I/O ports, memory, and DMA), and uconfig re-configures the UNIX kernel and drivers to match (sysadmin does not have to hack the /etc/conf directory). 5. Altos UNIX kernel is more optimized for larger UNIX systems, compared to SCO. Many of its tuneable parameters and non-tuneable internal parameters and structures have been adjusted to suit 100+ users. Altos UNIX supported 256MB since day one, even though the 5000 hardware currently supports up to 64MB. New versions of the Altos EISA systems will soon support 128MB-256MB, and will have the 33MHz or 50MHz version of the 486 CPU. In contrast, SCO had just broken the 16MB barrier with its 3.2.2 release, and how much memory can your XYZ PC support? 6. Altos has also fixed several bugs inherent in the 386 UNIX source code that caused performance penalties. I cannot reveal what these are because they are proprietary information. Now the "intangibles": 1. On many occasions when we qualify OEM hardware (for example, SCSI disks and tape drives) we find problems in compatibility. For example, the 525MB cartridge tape drive took many revisions to its firmware before it became bug-free enough to pass Altos requirements. Also, some SCSI disk drives have timing characteristics that does not work with the existing controller hardware (and required a change to the disk drive hardware). Instead of asking the the VAR or the customer to integrate pieces of hardware and software that may not work optimally together, Altos has provided a tested and proven platform, engineered from the start to work together. 2. Since the software and hardware are all from Altos, we can provide superior support for our VARS and customers. Altos' technical support team has been specifically trained to handle the Altos systems. If one had bought an XYZ PC with SCO UNIX, and expansion boards and device drivers from 5 other vendors, he/she might find no useful help from any of them when problems arise. 3. Since Altos builds turn-key solutions, you don't have to go to another vendor to acquire networking connectivity and other applications. Altos ships a very large selection of local area network and wide area network products, office automation applications, languages, and much, much, more. This goes back to the idea that dealing with one company that provides the total solution is easier than dealing with several. Collectively, these factors should make Altos software and hardware platform attractive to the market segment that wants a powerful, high performance UNIX system, but has no time or resource to do their own system integration and debugging. The PC-like open architecture is just an added bonus (remember, Altos has previously been building proprietary multi-user systems. These EISA systems mark the first time Altos has gone with an industry-standard architecture). I guess the bottom line is, if you feel that your XYZ PC and SCO or Interactive UNIX works fine for your application, great. Both SCO and Interactive have done a commendable job of putting UNIX on the PC-class platform, and are quality products. Altos offers enhancements that may or may not be useful to you. For installations that requires the additional performance, reliability, and expandability added by Altos, we offer the solution. -Ti -- Ti Kan \\\ vorsprung durch technik! \\\ Internet: ti@altos.com /// \\\ UUCP: ...!{sun|sco|pyramid|amdahl|uunet}!altos!ti ////////\
shwake@raysnec.UUCP (Ray Shwake) (08/29/90)
What we DON'T need here is a spitting contest between the vendors of Intel UNIX. I currently spend time with SCO's Xenix/386 and ODT products, and ISC's latest 2.2, and used to administer an Altos 3068. While I haven't yet spent time with Altos' new line, I was always quite impressed with the reliability and performance of their old line. They pulled a helluva lot of performance out of the old Moto 020; we ran whole departments on them. As Bart might tell Dick, "Don't have a cow, man!" The Altos, like others of its ilk, seek to promote integrated solutions, and having both knowledge and control of hardware and software allows one both to push performance higher and avoid many potential incompatibilities. Yes, you pay a price for this, but note how many postings in this group are of the "I can't seem to get [product x] to work properly with [product y]" variety. There's a place in this world for integrated solutions, as there is for unbundled hardware and shrink-wrap software.
ti@altos86.Altos.COM (Ti Kan) (08/30/90)
In article <1990Aug28.120429.29769@turnkey.tcc.com> jackv@turnkey.TCC.COM (Jack F. Vogel) writes: >GOSH, you "worked closely with the source", how close exactly, 10 feet?? >Or was the fileserver right next to your desk :-}. Did you get to touch >it at all :-} :-}??! > >Jack F. Vogel jackv@locus.com Sounds like you are nit-picking. Yes, I do have access to all of our UNIX source code, and I work on kernel development, device drivers, utilities, and other Altos value added software. Satisfied? -Ti -- Ti Kan \\\ vorsprung durch technik! \\\ Internet: ti@altos.com /// \\\ UUCP: ...!{sun|sco|pyramid|amdahl|uunet}!altos!ti ////////\
rcd@ico.isc.com (Dick Dunn) (08/31/90)
shwake@raysnec.UUCP (Ray Shwake) writes: > What we DON'T need here is a spitting contest between the vendors > of Intel UNIX... Agreed. > As Bart might tell Dick, "Don't have a cow, man!"... I think Bart might tell Ti Kan something similar...or perhaps something like "Hey, dude! It's just a machine, man..." And he'd be right in both cases...I won't plead innocent. I'm not very good at Bartspeak, but maybe I could make my point more clear by stating it more mildly? What I was getting at is that there aren't these major night-and-day differences among vendors. We all work closely with the source code. We all have a serious interest in performance. All software folk who deal with hardware talk to the hardware folks to try to get it right. It really doesn't matter all that much that the hardware folks are in other companies; the goal is still to get good, reliable, cheap performance. I don't think that a software engineer at Altos has any real qualitative advantage over one working at SCO, ISC, Esix, etc. Nor do I think that the hardware folks at WD, Adaptec, etc., would care to be told they're not able to build boards with the same sort of performance that Altos can get. The differences are quantitative. Sometimes its an advantage to have the hardware folks in-house; sometimes you're better dealing with an outside vendor who has a larger market and can do some things better based on sheer quantity. Sometimes you have leverage in-house by saying "here's what we need, and we're your only customer"; sometimes you have leverage outside by saying "if you can't build it, we'll get X to build it." I've done my time on both sides of this. That's why I took some offense at the suggestion that we can't spare the development effort for optimizations... it just ain't so. Or take the "number of users" issue. OK, at some level of use (say non- intensive data entry and some record processing) you can put 200 "users" on the Altos 5000. And it's true that other 486es are used as single- user workstations. But that's apples-to-oranges, and there's an apples- to-apples comparison possible: How many users can you put on some other 486 machine with reasonable disk space, etc.--*assuming* the same kind of user as the 200 on the Altos machine? A guess might be > 50 and < 100... but we're back to a matter of degree, especially when you start factoring in costs. >...The Altos, like > others of its ilk, seek to promote integrated solutions,... And that's valuable. They play by a slightly different set of rules than we do; that gives them different advantages. But the markets still over- lap a lot. > ...Yes, you > pay a price for this, but note how many postings in this group are of the > "I can't seem to get [product x] to work properly with [product y]" > variety... True, but you don't have to get yourself into that. You can take a list of "safe" known-to-work hardware combinations and build all your systems that way; if it's not on the list, don't buy it. ISC, SCO, et al, are always in the situation of dealing with "The Frobozz 4-port serial voice VGA doesn't work when I have two drives on a tertiary Xyzzy controller." The integrated-system vendors don't have that problem because they don't offer that hardware combination. Either way, you lose. >...There's a place in this world for integrated solutions, as > there is for unbundled hardware and shrink-wrap software. ...bringing us back 'round to Ray's initial point: We don't need a spitting contest among vendors. I see a place in the world where either integrated or unbundled solutions are viable, so I think each camp ought to be more careful about telling the other that it can't possibly do the job. --- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...I'm not cynical - just experienced. -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...I'm not cynical - just experienced.
dtynan@altos86.Altos.COM (Dermot Tynan) (08/31/90)
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."
dtynan@altos86.Altos.COM (Dermot Tynan) (08/31/90)
In article <15812@bfmny0.BFM.COM>, tneff@bfmny0.BFM.COM (Tom Neff) writes: > > Still, paying twice or three times as much for the comfort of knowing my > box was developed as a dedicated UNIX super-micro is not worth it to me. That depends. Where do you get this figure from? It may be an AT&T practice to charge 2x to 3x, but it certainly doesn't apply to Altos. The Altos 5000 is priced in and around what HP and Compaq charge. If I remember correctly, it is cheaper (marginally) than either of them, when they are configured identically. For example, the 5000 comes standard with Ethernet, SCSI, minimum of eight serial ports, etc. However, I definitely cannot quote the real price, because I don't know it. And I certainly wouldn't like it if the sales team started editing source... :) There is a certain rule-of-thumb, that says that even with the decline of memory and cpu prices, machines reach a minimum retail price. For the 8088, this seems to be in the neighborhood of $400 - $600 (excuse the inaccuracy, I don't follow that market too closely anymore). For a '286 machine, the price is somewhat higher. For an EISA machine, the minimum memory width is 32 bits. Personally, I can't see EISA machines ever dropping below about $4,000 (prove me wrong, someone... please!!). When you add disk controllers, serial controllers, graphics cards, disk drives, ethernet, etc. This cost hits an average. On top of that, you have the OS included, and Technical Support. In pieces, you could probably get a cheaper machine, but it wouldn't have the same kind of performance, because we'll always have an edge when we can tune the OS, and the hardware. At the same time, the figure would be lucky to be 20% more expensive (lots of hand-waving here, I only have vague recollections of pricing charts). Is the performance worth that?? Don't forget, we're all paying Intel through the nose right now, for their magic. When the i486 drops in price (which it undoubtably will), this will be reflected in the end price. > Of course, I don't fall in whatever specialized vertical niche it is > where you need to support 200 terminals on a single CPU. My guess is > that anyone in that niche should shop around for a system that meets > those special needs, pay what it costs even it's more than a PS/2 costs, > and count himself lucky -- the heck with what the rest of us think. Well, I guess we all quickly forget our educational background. I *still* log on to University machines, and am amazed that I was able to tolerate the poor performance, given the number of users. Especially when I see systems today (the 5000 included), which sell for MUCH less, and deliver a lot more performance. Altos machines are used by a lot of airlines, for their ticket desks (no, its not *our* fault the airlines are late :), throughout the country. They are also used for ATMs. These are the unusual installations. A lot of the installations are more "mainstream", and believe me, there is nothing "niche" about supporting 200 users. Ask Brandon Allbery. He has a much better idea of what the "typical" Altos user looks like. But don't kid yourself. Most of us on this net seem to assume that the overwhelming use for computers today, is compiling C programs, and reading news. This is far from true. It's a major reality break to find that most users of computers don't know UNIX from OS/2, and couldn't care less. They have some particular task or function they want to do. If the computer can help them and make them more productive, that's all they want to know. SERMON MODE ON: In this day and age we are all running around claiming MIPS this, RAM that, when the *real* customers couldn't care whether the machine ran DOS, CP/M or awk, as long as they can do their work better and/or faster. We would all be better off focusing on what the end-user is trying to do, instead of hitting him/her over the head with so much useless trivia. SERMON MODE OFF: As far as Altos is concerned, if you can support 200 users on one machine, as well has you could with 200 smaller and cheaper machines, then the economies of scale are in favor of the 200-user machine. Whatever about the PC revolution, as long as that is the case, the 200-user machine will prevail. As soon as that isn't the case, we need to re-evaluate. Given that the entry price of an equivalent PC would be $400, that means that the cost of putting 200 machines out there would be $80,000, not including network costs. We can beat that figure by a considerable margin. That is no "niche market"! - 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."
jmm@eci386.uucp (John Macdonald) (08/31/90)
In article <1990Aug30.181157.16638@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes: |shwake@raysnec.UUCP (Ray Shwake) writes: |> What we DON'T need here is a spitting contest between the vendors |> of Intel UNIX... | |Agreed. |I don't think that a software engineer at Altos has any real qualitative |advantage over one working at SCO, ISC, Esix, etc. Nor do I think that |the hardware folks at WD, Adaptec, etc., would care to be told they're not |able to build boards with the same sort of performance that Altos can get. |The differences are quantitative. Sometimes its an advantage to have the |hardware folks in-house; sometimes you're better dealing with an outside |vendor who has a larger market and can do some things better based on |sheer quantity. Sometimes you have leverage in-house by saying "here's |what we need, and we're your only customer"; sometimes you have leverage |outside by saying "if you can't build it, we'll get X to build it." I've |done my time on both sides of this. That's why I took some offense at the |suggestion that we can't spare the development effort for optimizations... |it just ain't so. While I generally agree with Dick's comments, I think that Ti's original comments did have some basis too. If the developers are working in a limited environment where there is a small number of supported boards (whether they are made internally or by an outside party) they can spend more time after getting it working to get it working really well. If they must support every piece of hardware that any customer might happen to add on, then it is quite possible that they never reach the stage where all the combinations are working and they have time to work on the optimization. Often, if you have to work with a large number of differrent types of hardware, you may decide to skip any optimizations that require a change to each hardware-specific device driver. There *is* a qualitive difference between doing a large number of things well and doing a smaller number of things better. Depending upon the number and quality of people that each manufacturer has, it is not however impossible to do either a large number of things better or a small number of things worse, however... Glad to see the discussion moving away from marketing and bickering towards technical facts (contrary to normal usenet practice :-) ... -- Algol 60 was an improvment on most | John Macdonald of its successors - C.A.R. Hoare | jmm@eci386
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/KT) (09/02/90)
I usually try to keep my mouth shut about the Altos, since I'm not here to provoke flame wars. Nevertheless, I seem to have started something. As quoted from <43@raysnec.UUCP> by shwake@raysnec.UUCP (Ray Shwake): +--------------- | As Bart might tell Dick, "Don't have a cow, man!" The Altos, like | others of its ilk, seek to promote integrated solutions, and having both | knowledge and control of hardware and software allows one both to push | performance higher and avoid many potential incompatibilities. Yes, you | pay a price for this, but note how many postings in this group are of the | "I can't seem to get [product x] to work properly with [product y]" | variety. There's a place in this world for integrated solutions, as | there is for unbundled hardware and shrink-wrap software. +--------------- This was exactly my point in the reply that started all this. I've had plenty of experience trying to get serial port boards to work on various 286/386 PCs; I have yet to have such problems even on the 5000. And even if I did have a problem of that sort (the original MultiDrop had its share of "version 1" problems), it's much easier to get things fixed when the computer, O/S, and board vendors can't run around pointing fingers at each other. Sure, you pay for it (but not *that* much more; we priced out a 386 PC against an Altos 1000 and got pretty much equal prices after adding in the stuff that the ads in PC magazines don't tell you about, like needing more memory and larger drives to get an equivalent system), but having a single support organization which knows about *all* your hardware and the operating system makes up for it. Consider the cost of support --- both in money and in time --- and the integrated approach looks much better. Telotech has a number of customers who came to us after finding this out the hard way. I think I'll cut my comment short there, as I *still* don't want to plug my company or the stuff we sell on the Usenet. And I'll second the vote to put a damper on the system-wars flames. If you want to discuss this stuff with me, do it via mail --- same most likely goes for Der Tynan and Ti Kan at Altos. I'm on this newsgroup to look for and provide information, not participate in silly religious wars. ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR/KT on 220, 2m, 440 Internet: allbery@NCoast.ORG Delphi: ALLBERY uunet!usenet.ins.cwru.edu!ncoast!allbery America OnLine: KB8JRR