NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/sys/ibm/pc/hardware/34211

Text File | 1992-12-26 | 8.5 KB | 172 lines

Newsgroups: comp.sys.ibm.pc.hardware
Path: sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!zazen!doug.cae.wisc.edu!keiths
From: [e-mail] (Keith Scidmore)
Subject: Choosing a drive. (Was Fast hard drives - seek isn't everything.)
Organization: College of Engineering, Univ. of Wisconsin--Madison
Distribution: na
Date: 26 Dec 92 11:23:20 CST
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Lines: 160

OK you people, you've pissed me off enough to respond publically. (LONG)
This is hpefully an informative flame war - Choosing a hard drive.


In article <[e-mail]> I wrote:

>I asked Hard Drives Intl for their fastest IDE drive (thinking I would
>let Zeos keep the Seagate 3283A 245MB drive that came with my system
>and upgrade immediately).
>HDI sent me a $1000 FJ2624A 510MB Fujitsu IDE drive.


In article <[e-mail]>, [e-mail] (Oscar the Grouch) writes:
> So they sent you what you asked for the disk with the fastest published specs

No, we discussed many parameters but the point of my posting was not to
describe how I picked the hard drive.  The point is that the measure
everyone keeps pointing to as the key to determining what drive they should
(average seek) is not reliable.  In my tests, even a very high seek rate
advantage (~8ms vs ~11ms measured) didn't result in better performance
under actual system loads.

HDI claims to do their own testing and openly said that they consider
published specs to be unreliable.  The point is that advertisers, including
HDI, omit other information that is at least as important as average seek.
My unsuccessful attempt to upgrade was a good example of this.  I did
everything I reasonably could to determine which product would give me
the speed upgrade I was looking for.  But it failed the ultimate test. My
programs ran slower.

The problem is that even companies like HDI that make an honest effort to
protect their customer from false claims can't tell you what you need to
assess a drive's performance.

In article <[e-mail]> I went on to write:
>The Seagate was 10-20% faster than the Fujitsu on all my program tests.  The
>reason is that the Fujitsu drive was about 18% faster on seek times but the
>Seagate was about 50% faster in transferring the data.  I returned the
>Fujitsu to HDI.

In article <[e-mail]>, [e-mail] (Oscar the Grouch) responds:
> So who paid for your learning experience. Sounds like HDI did.

I had every intention of keeping the drive if it outperformed the drive
I was using.  The possibility of a return was even discussed with the
salesman!

> So let me guess, after installing the disk, beating hell out of it with
> your testing program, and using it for some unmentioned period of time
> you returned it for a full refund. Not; because the drive was defective.
> Not because it did not meet the published specs. but because it did not
> live up to your expectations.

Wait a minute.  Isn't that what a return policy is for?  It allows people
to return murchanise that doesn't meet their expectations. It's not like
I make a habit of this.  It cost me about $30.

If I can beat the hell out of a drive in a few hours of use it seems to me
that it is of very poor quality.  Actually, I'd rather buy a drive that
had been "burned in" for a few hours than one that has not.

In article <[e-mail]> [e-mail] (roger.h.levy) writes:

>I agree that Keith has abused HDI's highly customer oriented policies.
>Also, Keith hasn't said enough to convince me that his testing was
>well controlled.  The fact that he didn't previously even understand
>the signficance of rotational latency casts a lot of doubt on his ability

This the part that pissed me off.  Rotational latency wasn't even discussed.
Roger, where the hell did you get the idea that I don't understand rotational
latency?  I intentionally kept the details to a minimum because I am
not writing a term paper.  The rotational velocity of the two drives were
close 4400 rpm for the Fujitsu and 4500 rpm for the Seagate.  If I can
believe my sources. Nonetheless, you missed the point.

THE ROTATIONAL LATENCY OF A DRIVE IS NOT A GOOD MEASURE OF ITS PERFORMANCE!
THE AVERAGE SEEK TIME OF A DRIVE IS NOT A GOOD MEASURE OF ITS PERFORMANCE!
THE NORTON, CORE, CHECKIT, PCTOOLS, ETC BENCHMARKS ARE NOT A GOOD MEASURE!
THE BUFFER SIZE OF A DRIVE IS NOT A GOOD MEASURE OF ITS PERFORMANCE!
THE ON-DRIVE CACHE SIZE ON A DRIVE IS NOT A GOOD MEASURE OF PERFORMANCE!
WHAT THE SALESMAN SAYS IS NOT A GOOD MEASURE OF PERFORMANCE!
ETC ETC ETC

All these factors enter into the picture but they can't be used to draw
a good conclusion about the drive's performance.  The only good measure
of a drive's performance is elapsed time on your system using the programs
you want to speedup.

This is why I reviewed the benchmarks and resorted to timing disk-intensive
programs I use, rather than dwell on issues such as Checkit turning off
the disks' cache/look-ahead buffers verses the other tests that don't.

Even with running programs there are many factors that need to be controlled.
Some you can't control. The Fujitsu should have had the advantage
in that the test programs occupied a smaller percentage of the disk
and therefor the test programs used a smaller percentage of the total
stroke, reducing effective seeks.  Both disks were defragmented,
contained identical data, and were tested alone as masters.

>to insure that all other factors were equal.  For example, the specs I
>have say the Fujitsu has a segmented 240KB read-ahead cache that "can
>be configured to further optimize drive performance and [provide] even
>faster data throughput."  Did you take a look at configuring the cache,
>Keith?  At 4400 RPM and a rotational latency of 6.8 msec, the Fujitsu

Roger, you just stuck you foot in your mouth to the knee.  You have the
specs for the SCSI version of the IDE drive I tested. The IDE drive has
64K.  There was no documentation supplied with the drive that described a
procedure for disabling the look-ahead buffer.

If configuration is important to getting the full performance
HDI should have provided it with the drive and the return was a result of
their omission of the information needed to properly set up the drive. This
would make my return of the drive even more justified.

* An important note is that one individual contacting me indicated        *
* that the Fujitsu dirves are often delivered with their caches disabled  *
* for reasons that escape us both. If you own one you might just check.   *

------------------------------------------------------------------------------
I must assume that these guys are offended Fujitsu fans.  All I can
say is one of the basics tought in most introductory computer architecture
classes.

          THE ONLY IMPORTANT MEASURE OF PERFORMANCE IS
          THE TIME IT TAKES TO RUN YOUR PROGRAMS.

On my system with my hardware the Seagate ST3283A ran my disk application
programs 10-15% faster than the Fujitsu FJ2624A.  Numerous test programs were
run using:

ZEOS 486DX2-66 VLB (Goose Motherboard)
16 MB memory

Operating Systems:
DR-DOS 6.0 with a 2MB software cache (SMARTDrive windows 3.1)
Windows 3.1 ( I know, it's not really an OS)
OS2 2.0 GA with HPFS and a 2MB software cache.

The test programs run were too numerous to list but I will say that there
was a deliberate effort made to force cache misses so as to assure that
the drives would be well exercised.  Software cache was included because
this is the way I set up my system.  This brings up an pitfall that is
worth mention.

Many drive are including not just look-ahead buffers, but on-drive cache.
If you run a large software cache, the tiny 240 KB cache on Rogers SCSI hard
drive can become virtually useless.  In some cases their may be conflicts
generated that make the drive run slower than it would without the cache.
See the January Computer Shopper sidebar "The SCSI Alternative: Extra
Performance, Extra Caution" for a probable example of this.

When the mags test these drives they don't use a software cache.  This
means that the drives with a large cache looks better than the
underlying hardware really is.  Adding a large software cache
eliminates most of this effect and the true speed of the drive hardware
becomes more significant.  There are also some unscrupulous disk manufacturers
that include cache hits in calculating their average seek times.

Keith