bruce@ACT.UUCP (Bruce Himebaugh) (10/12/90)
The purpose of this article is to summarize the responses I received, asking
for a comparison of Altos versus NCR.
In a nutshell, the original request went something like this:
What I am looking for is a good comparison of an Altos Series 5000 versus
what ever the equivalent is for NCR for a customer of ours.
The system will initially be configured for the following: 70 users, 20
printers, 3 modems, 24M-32M RAM, 600M-800M hard disk space and 300M-500M
tape drive. The system needs to have the future expandability of: 100
users, 30 printers, 3 modems, 48M-64M RAM, 1G-1.5G hard disk space and
300M-500M tape drive. The OS will be Unix System V (or equivalent). The
software they will be initially running on the system is: Multiplan
Spreadsheet, Uniplex Word Processing, some sort of user friendly mail
system (i.e. not /usr/bin/mail), programs running under MicroSoft compiled
basic, MultiView (i.e. like JSB's mview) and filePro+ 4.0 database from
Small Computer Company.
The most heavily used software will be the filePro+ database and the
compiled basic programs. The MultiView product will be used by 20 to 30
users. The other software will be used on and off, as needed by everyone.
Future software requirements will include such items as CAD and other
graphics related software. 95% of the people will be using standard ascii
terminals, but down the road some X capability might be needed also. SCO
compatibility would be nice, but not necessary.
Of course price/performance is the main issue. They want a fast system,
but a reasonably priced system, hence the price/performance issue is the
heavy factor.
Summary of responses received:
Altos:
- Altos 5000 is possibly a dead-end. Some upgradeability is in
question.
- An Altos 4000 is in the works that is a cut-down version of the 5000.
- An Altos with multiple-processor capability is in the works.
- The Altos' really shines in the area of disk I/O.
- Altos performance goes way down when using X windows.
- Altos uses the EISA bus.
NCR:
- NCR announced a switch to Intel chips. Motorola-based crud will
become white elephants.
- NCR is the slowest general purpose Unix box on the market.
- 2 people doing C compiles can drive an NCR to constipation.
- Less than 5 X terminals can "saturate" an NCR.
- NCR will be using a Micro Channel bus in the new Intel based
machines.
- Beware of possible availability/delivery problems while NCR makes the
switch to Intel. Especially with software.
Miscellaneous:
- "70-100 users on an Altos or NCR?? What are they going to be doing,
or, better yet, what have you been smoking lately??!!"
- One suggestion was to investigate a Sequent.
- One suggestion was to investigate AT&T's StarSERVER-E.
- "First models of the new NCR line, as well as the Altos, seem to be
well regarded."
I really appreciate all responses that I received! Although I must say that I
was sort of disappointed in the fact that I got no responses from NCR or
Altos. I guess I was also hoping for more information regarding the actual
performance of each system. If anyone else would like to respond, please do
so, as the decision has still not been made.
Thanks again for everyone's help!!!
Bruce
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Bruce Himebaugh A.C.T. Consulting, Inc. Voice: 216-455-1444
PATHS: uunet!{ncoast,aablue}!fmsystm!mrsmouse!bmhalh!ACT!bruce
(NOTE: the system name "fmsystm" is with no "e", NOT "fmsystem")
*NOTE*: Please do not use bruce@ACT.UUCP -- I'm not registered yet.peter@ficc.ferranti.com (Peter da Silva) (10/17/90)
> - NCR announced a switch to Intel chips. Motorola-based crud will > become white elephants. RISC versus CISC aside, using the term "crud" to refer to the 680x0 by comparison with the 80x86 makes me wonder about someone's sanity. Sure, the intel chips are currently on the high end of the see-saw: but wait till the 040 starts shipping in quantity. And what the compilers have to do to get that performance make RISC compilers seem simple. I think we need a new term for intel chips: IISC, "Insane Instruction Set Computer". The 80386/80486 are almost civilised, but they're still stuck with a highly inhomogenous register file. We've got a 68000-based (yes, the old one) UNIX box that blows our 386 boxes out of the water. For multiuser use the surrounding hardware is at least as important as the CPU. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
cedman@lynx.ps.uci.edu (Carl Edman) (10/17/90)
In article <YZG6DXD@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
RISC versus CISC aside, using the term "crud" to refer to the 680x0 by
comparison with the 80x86 makes me wonder about someone's sanity. Sure, the
intel chips are currently on the high end of the see-saw: but wait till
the 040 starts shipping in quantity. And what the compilers have to do
to get that performance make RISC compilers seem simple.
Just a short and (IMHO funny) note: Do you know how many instructions
a RISC (Reduced Instruction Set Coding) CPU by IBM has ? 186 !
Yes, this is the number of the machine instructions for the new
IBM 6000 series.
Carl Edman
Theorectial Physicist,N.:A physicist whose | Send mail
existence is postulated, to make the numbers | to
balance but who is never actually observed | cedman@golem.ps.uci.edu
in the laboratory. | edmanc@uciph0.ps.uci.edusleepy@wybbs.mi.org (Mike Faber) (10/18/90)
In article <YZG6DXD@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: Comments about 80x86 and 680x0 chips here... > >We've got a 68000-based (yes, the old one) UNIX box that blows our 386 >boxes out of the water. For multiuser use the surrounding hardware is >at least as important as the CPU. >-- >Peter da Silva. `-_-' Thank you. I've been saying (to my boss mostly) that the disk speed and quantity are the REAL deciding factors in a resonably designed system. In my opinion, the only thing you need a CPU for in a typical DBMS computer is to direct traffic, and make an occasional computation here and there. -- Michael Faber sleepy@wybbs.UUCP
mjr@hussar.dco.dec.com (Marcus J. Ranum) (10/18/90)
In article <505@wybbs.mi.org> sleepy@wybbs.UUCP (Mike Faber) writes: >In article <YZG6DXD@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >> >>We've got a 68000-based (yes, the old one) UNIX box that blows our 386 >>boxes out of the water. For multiuser use the surrounding hardware is >>at least as important as the CPU. > >Thank you. I've been saying (to my boss mostly) that the disk speed and >quantity are the REAL deciding factors in a resonably designed system. >In my opinion, the only thing you need a CPU for in a typical DBMS computer >is to direct traffic, and make an occasional computation here and there. For truly optimal performance, you should choose your hardware based on your expected demands, not such general statements like "I/O bandwidth is most important" or "lots of RAM never hurts" or "how many MIPS has that thang got?". Ideally, before going into a computer buy you should know roughly what your load is - presumably some Real Life Accounting Information might help a lot. Monitoring the performance characteristics of any current (or similar) systems to see what their shortcomings are doesn't hurt any, either. If you just say flat out, "you need MIPS" - you're wrong. The correct answer is ALWAYS, "It depends." Lots of I/O bandwidth isn't going to help a lot if all the machine does is ray-traces. The best way to get optimal performance for your dollar is to buy a balanced machine. Balanced for your expected usage. You don't go out and buy a Testarossa if you live in LA or someplace that's a wall to wall traffic jam, and you don't buy a Yugo if you're planning on running at Indy. (Ok, some tacky folks in LA buy Testarossas and sit in the freeway idling - your computer can do roughly the same thing). mjr. -- Nothing is beautiful unless it is large. Vastness and immensity can make you forget a great many weaknesses. - Emperor Napoleon I
jfh@rpp386.cactus.org (John F. Haugh II) (10/18/90)
In article <CEDMAN.90Oct17082702@lynx.ps.uci.edu> cedman@lynx.ps.uci.edu (Carl Edman) writes: >Just a short and (IMHO funny) note: Do you know how many instructions >a RISC (Reduced Instruction Set Coding) CPU by IBM has ? 186 ! >Yes, this is the number of the machine instructions for the new >IBM 6000 series. the definition which seems to be in place at IBM regarding the S/6000 is "reduced instruction set cycles". one of the early goals of RISC was to have every instruction execute in one clock (with the possible exception of load and store). the S/6000 may execute as many as 5 instructions in a single clock. so in one sense it is still very RISC-like, it just has too damned many instructions for some people. my next question is - who cross-posted this thing to so many newsgroups??? -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org "SCCS, the source motel! Programs check in and never check out!" -- Ken Thompson
tif@doorstop.austin.ibm.com (Paul Chamberlain) (10/18/90)
Sorry for the out-of-topic stuff but I just found a good signature quote: mjr@hussar.dco.dec.com (Marcus J. Ranum) writes: >... The correct answer is ALWAYS, "It depends." ... Was that original? Paul Chamberlain | I do NOT represent IBM. tif@doorstop, sc30661 at ausvm6 512/838-7008 | ...!cs.utexas.edu!ibmaus!auschs!doorstop.austin.ibm.com!tif
cowan@marob.masa.com (John Cowan) (10/19/90)
In article <18601@rpp386.cactus.org>, jfh@rpp386.cactus.org (John F. Haugh II) writes: >In article <CEDMAN.90Oct17082702@lynx.ps.uci.edu>, > cedman@lynx.ps.uci.edu (Carl Edman) writes: >>Just a short and (IMHO funny) note: Do you know how many instructions >>a RISC (Reduced Instruction Set Coding) CPU by IBM has ? 186 ! >>Yes, this is the number of the machine instructions for the new >>IBM 6000 series. > >the definition which seems to be in place at IBM regarding the >S/6000 is "reduced instruction set cycles". I actually asked about this point when IBM came out with the RT machine. The answer was: "The official IBM definition of RISC is 'Any IBM machine with fewer instructions than a System/360'". This comes about because all IBM RISC work began with the 809, an attempt to strip down the S/360 instruction set. -- cowan@marob.masa.com (aka ...!hombre!marob!cowan) e'osai ko sarji la lojban
floydf@iphase.UUCP (Floyd Ferguson ENG) (10/22/90)
In article <505@wybbs.mi.org> sleepy@wybbs.UUCP (Mike Faber) writes: > >Thank you. I've been saying (to my boss mostly) that the disk speed and >quantity are the REAL deciding factors in a resonably designed system. >In my opinion, the only thing you need a CPU for in a typical DBMS computer >is to direct traffic, and make an occasional computation here and there. > Only if the DBMS by-passes the UNIX filesystem via the raw device. If your data is accessible via filesystem, your CPU will spend most of its time just running the filesystem, and you will see a noticeable improvement by adding horsepower. -- Floyd Ferguson uunet!iphase!floydf
pavlov@canisius.UUCP (Greg Pavlov) (10/25/90)
In article <505@wybbs.mi.org> sleepy@wybbs.UUCP (Mike Faber) writes: > >Thank you. I've been saying (to my boss mostly) that the disk speed and >quantity are the REAL deciding factors in a resonably designed system. >In my opinion, the only thing you need a CPU for in a typical DBMS computer >is to direct traffic, and make an occasional computation here and there. > I don't buy that. Once again, this is probably one of those "it depends on your application..." issues. But if one has large tables on which one per- forms complex joins, the cpu has a lot of work to do, well beyond the "occasional computation here and there...". Computation is the least of it; it's the compares and other functions related to selecting the correct data that takes all the time, in such applications. This is especially true if one has chosen his/her keys and indices carefully and accesses a good query optimizer (such as INGRES's, prior to Version 6...) greg pavlov, fstrf, amherst, ny pavlov@stewart.fstrf.org 716-834-0900