Summary of Request for Comparison of Altos and NCR

Marcus J. Ranum mjr at hussar.dco.dec.com
Thu Oct 18 13:19:29 AEST 1990


In article <505 at wybbs.mi.org> sleepy at wybbs.UUCP (Mike Faber) writes:
>In article <YZG6DXD at xds13.ferranti.com> peter at 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



More information about the Comp.unix.internals mailing list