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