Path: utzoo!attcan!utgpu!watmath!att!dptg!rutgers!cs.utexas.edu!uunet!cbmvax!snark!eric
From: eric@snark.uu.net (Eric S. Raymond)
Newsgroups: comp.arch
Subject: Re: more soap box
Message-ID: <1SsYy5#6pYhHg=eric@snark.uu.net>
Date: 21 Sep 89 14:53:40 GMT
References: <21962@cup.portal.com> <1989Sep12.031453.22947@wolves.uucp>
  <22130@cup.portal.com> <1989Sep16.044013.429@wolves.uucp>
  <259@ssp1.idca.tds.philips.nl> <22308@cup.portal.com>
Lines: 27

In <22308@cup.portal.com> Cliff C Heyer wrote:
> the *big iron* guys use MIPS as a trojan horse to hide the *real*
> performance issue - "real world" I/O bandwidth. Lets blow their
> cover!)

Huh? The `big iron' crowd is happy to talk I/O bandwidth, it's about the
only place general-purpose mainframes got room to shine any more. It's
the *PC/workstation* crowd that's prone to yell about MIPS and whisper
about I/O performance.

As well they might. For most job-mixes, 16MHz+ UNIX micros are disk-limited
rather than processor-limited. To see this, rip out your crufty old ST406/512
controller/drive pair and drop in a track-buffering ESDI or SCSI controller
with 1:1 interleave -- and watch your real performance *double*.

Part of this is low bus bandwidth (especially on AT-bus machines) but most is
simply that processor technology has outrun mass-storage technology, very much
as happened a decade ago when the VAX and other second-generation minis got
off the ground (the parallel is reinforced by the strong similarity between
present micro architectures and those minis -- go compare the 680x0
instruction set to a PDP-11's sometime).

Barring a quantum leap in mass-storage technology, this gap is probably going
to get wider rather than narrower. Therefore, expect the MIPS smoke-and-mirrors
to get *more* intense...
-- 
      Eric S. Raymond = eric@snark.uu.net    (mad mastermind of TMN-Netnews)