Xref: utzoo comp.unix.i386:644 comp.unix.xenix:7891
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!crdgw1!crdos1!davidsen
From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr)
Newsgroups: comp.unix.i386,comp.unix.xenix
Subject: Re: Mylex SCSI Controller, 16550A UARTS
Message-ID: <765@crdos1.crd.ge.COM>
Date: 3 Oct 89 17:10:30 GMT
References: <111016@nstar.UUCP> <707@fiver.UUCP> <2834NU013809@NDSUVM1> <22709@cup.portal.com>
Reply-To: davidsen@crdos1.UUCP (bill davidsen)
Followup-To: comp.unix.i386
Organization: GE Corp R&D Center
Lines: 43

In article <22709@cup.portal.com>, cliffhanger@cup.portal.com (Cliff C Heyer) writes:

|  I'm hoping that if I am wrong, someone will be able to give me a convincing
|  argument otherwise.

How about a few facts?

A) typical ESDI drives (looking a a recent spec sheet) turn 3600 rpm,
have 32 sectors of 512 bytes. 32*512*60/1024 = 960kb max from ESDI, no
allowance for latency, step time, etc.

B) I measured the ballpark i/o of several machines by doing a dd of the
raw device to /dev/null. Crude, but it shows about 600kb for my ESDI
system, the same for my RLL system, about 500kb for a microvax 3500
(Ultrix) and about 700 for a Convex C220.

C) Looking at the loading on a small number of Suns, 386s, and one
MicroVAX, I conclude that most processes which are not doing terminal
i/o are CPU bound, and that "wait for i/o" is only 20% of the total
clock time to run. I had to check this with several tools, so results
are not perfect.

  From this set of reasonably useful numbers I would suggest that you
could look for a less demanding solution in any of the following areas:
is your application really transfer rate bound? Do the figures you
quoted for other machines reflect actual performance, benchmark
performance, or hardware limits? Are you asking for something which
isn't being marketed?

  The only thing you implied with which I disagree is the implication
that people will grom out of 386 type systems in the i/o end. I really
don't believe that's typical of the usage I've seen. Adding memory to
avoid page/swap and provide buffering seems to keep the i/o going long
after the CPU cycles are gone. This obviously depends on usage, but I
think the loads I see are typical (a mail gateway, development machine,
and general office automation).

  Good luck in finding something which will run your application.
-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
"The world is filled with fools. They blindly follow their so-called
'reason' in the face of the church and common sense. Any fool can see
that the world is flat!" - anon