🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.ibm.pc.hardware.misc
Article #606

Re: Is it possible to actually get a 16 MB/sec data transfer rate w/ an EIDE drive?

#606
From: Ron Reaugh
Date: Thu, 18 Dec 1997 00:00
102 lines
5678 bytes


Michael Wong <nospam_mikwon@ebtech.net> wrote in article
<3498a647.4325910@news.ebtech.net>...
> >>     I've been reading the part of this thread to do with access
> >>  rather than EIDE/SCSI in a somewhat bemused fashion.  Let's skip
> >>  the parts that are to do with stand-alone systems (most of the
> >>  posters are discussing servers), 
> 
> >I believe this is your mistake.  I thought we were talking client
> >or stand'alone systems when we were discussing the lack of merit 
> >of SCSI.  I don't believe anyone questioned SCSI's usefulness in 
> >a server. 
> 
> Also, the thread basically started as a discussion over whether a hard
> drive rated for 16MB/sec theoretical transfer rate would actually
> achieve that kind of transfer rate under real-world conditions.
> Naturally, the argument then turned to a discussion of whether
> "real-world" meant contiguous block transfers, heavy random I/O, or
> multiple simultaneous transfers.
> 
> >You haven't followed this discussion long then.  My argument is 
> >that on a client workstation SCSI is useless, with one (as I 
> >noted) or two exceptions.  On a server, SCSI is obvious because 
> >of the multiple requests and drive optomization allowed.  Not all
> >drives are created equal either. 
> 
> The problem with thise argument is that most people don't really need
> serious disk performance (gasp!).  Whether it be EIDE or SCSI, slow
> hard drives are perfectly acceptable on most workstations (the
> garden-variety workstations that are suitable for EIDE) provided that
> they are not AGONIZINGLY slow, so naturally, the cheap EIDE drives are
> the better choice.
> 
> In spite of what some may suggest, this isn't really a discussion of
> two technologies which are suited for different applications.  This is
> a discussion of two technologies, one low-end and one high-end, where
> the slower technology (and yes, it's slower) is suitable for most
> people who don't need serious speed.
> 
> What's serious speed?  Ron Reaugh thinks that serious speed is a high
> transfer rate irrespective of seek times, latencies, and all of the
> multitasking optimizations in SCSI drives and controllers.


Ther ya go attributing things to me that are flat false.  I've said
workstation performance is STR dominated with access time as a strong
second place.


>  But the
> problem with this argument is that any application which truly NEEDS
> high disk performance is also going to be one of those "rare"
> applications that needs SCSI's particular advantages, even on a client
> workstation.  The rest of the garden-variety apps don't need SCSI's
> particular advantages, but they don't even need high-end EIDE.

That's nonsense.  Many workstations are disk bound.  Therefore disk I/O
performance improvements have a first order impact on performances for
these cases.  In most cases on a disk I/O bound workstation equivalent
performance can be achieved using either UDMA EIDE drives like the IBM
Deskstar 5/8 or 7200 RPM UW SCSI.  10K RPM SCSI is the fastest and most
expensive.

> 
> >Sure, this is a server.  This is not what was being discussed 
> >(unless I cross-threaded things again).  Anyone who would argure 
> >against SCSI (vs. IDE) for servers is nuts.  On the desktop 
> >things reverse.
> 
> This argument has been continuing for some time now, and I would SORT
> OF agree except to revise your distinctions to group high-end
> workstations and servers together for SCSI suitability, and low-end
> workstations for EIDE suitability.  EIDE's great for its design
> purpose (low-end workstations), but the "ultimate wet dream
> workstation" of every knowledgeable power user comes with SCSI

That's last years fantasy.

> (probably a pair of Cheetahs on a DPT caching RAID controller), even
> though it's not a server.
> 
> Is it NECESSARY for most people?  Of course not, but neither is a
> 300MHz CPU, or 128MB of SDRAM, or an 8MB video card.  That doesn't
> change the fact that it's BETTER if you can afford it, even on a
> single-user workstation (just like all of those things).  Let's face
> it- for the "average workstation" that Ron Reaugh is talking about,

Again it's nice to be so frequently quoted but maybe just once in a while
you could get it right as you didn't again.  High performance workstation
users should consider UDMA solutions and possibly the FastTrak as Cheetah
like performance is achievable and bigger and less expensive.

> an
> obsolete P133 with 32MB of RAM, a 2MB video card, and a 2.5GB EIDE
> hard disk is perfectly adequate.

Regards,

Ron Reaugh
 
Technical Details
Message-ID: <67am71$7v2@mtinsc03.worldnet.att.net>
Path: arc1-ca.pugleaf.net!unknown!not-for-mail
References: <348c422b.31666353@news.demon.co.uk> <881691095snz@inf-eden.demon.co.ux> <pLMYl5dhX7hK-pn2-bmRtSYdnH0CM@ALEX> <3498a647.4325910@news.ebtech.net>

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 1036bc,aad589958d8c66fd
X-Google-Attributes: gid1036bc,public
X-Google-Thread: 1045b9,aad589958d8c66fd
X-Google-Attributes: gid1045b9,public
X-Google-Thread: 109e38,aad589958d8c66fd
X-Google-Attributes: gid109e38,public
X-Google-Thread: f5f89,aad589958d8c66fd
X-Google-Attributes: gidf5f89,public
X-Google-Thread: f4d7c,aad589958d8c66fd
X-Google-Attributes: gidf4d7c,public
From: "Ron Reaugh" <Ron-Reaugh@worldnet.att.net>
Subject: Re: Is it possible to actually get a 16 MB/sec data transfer rate w/ an EIDE drive?
Date: 1997/12/18
Message-ID: <67am71$7v2@mtinsc03.worldnet.att.net>
X-Deja-AN: 299280136
References: <348c422b.31666353@news.demon.co.uk> <881691095snz@inf-eden.demon.co.ux> <pLMYl5dhX7hK-pn2-bmRtSYdnH0CM@ALEX> <3498a647.4325910@news.ebtech.net>
Organization: MBR International
Newsgroups: comp.sys.ibm.pc.hardware.misc,comp.sys.ibm.pc.hardware.chips,demon.tech.pc,alt.comp.hardware,comp.sys.ibm.pc.hardware.storage