[Alug] Hard Drive performance
James - listmail
jtl2nospam at myrealbox.com
Wed Sep 18 10:58:01 BST 2002
Date: Tue, 17 Sep 2002 08:51:36 +0100
To: Ian Bell <ruffrecords at uklinux.net>
Cc: main at lists.alug.org.uk
Subject: Re: [Alug] Hard Drive performance
From: Adam Bower <abower at thebowery.co.uk>
On Mon, Sep 16, 2002 at 10:44:33PM +0100, Ian Bell wrote:
> I mentioned in an earlier post my move from a P!! igig PC to a new dell
> laptop with a P4 1.6 gig and how with rh7.3 it seemed slower than the old
> system. I have now investigated this a little further.
< Snippage - Topic is DMA settings To use, or not to use hdparm... >
>Oh and finally hdparm can destroy data on your harddisk if you go for too many
>settings and the disk/computer doesn't like them....
Too right! ( For details, and a little PC history read on... )
Subject: Re: [Alug] Hard Drive performance
From: Douglas Willis <ddw at bas.ac.uk>
To: Alug Mailing List <main at lists.alug.org.uk>
Date: 17 Sep 2002 09:24:48 +0100
>On some of the earlier laptops turning on DMA caused the cdrom drives to
>lockup requiring a hare reset of the machine. I this was due to
>slightly non standard IDE bus architecture.
>I run an IBM A21M which has a PIII ant about 800MHz and now have no
>problems with disk access once I turned on the DMA settings.
>The RedHat install by default disabled the DMA .
This is considered ( quite rightly ) to be the safest default option that
will operate properly across all PC architecture hardware.
The old timers may remember the war that IBM fought to keep their PC hardware
and firmware (BIOS) proprietary - forcing competitors making clone machines
to do "clean room" BIOs coding and design their own hardware, too. Gaining
a cost and time to market advantage for IBM for quite a while. It guaranteed
a lot of flaky hardware designs, too. ( Remember the Amstrad 286 HD fiasco? )
Compaq were established in this era; and never quit designing their own
hardware. Even today, when it is no longer necessary, or desirable, to deviate
too far from accepted "industry standards". They were beginning to get wise
to the fact that it is no longer desirable! Two decades later... Only to
be swallowed by HP. Go figure.
It is cheaper to use "industry standard" chipsets from a third party than
to re-invent complex hardware, in the design process. Some big corporations
just failed to adapt, and tried to lock in customers to their particular
hardware, when the game had moved on to proprietary lock-ins via software:
EULAs and proprietary protocols "embracing and extending" open standards.
I can pretty much guarantee data loss ( or total operating system loss ) on
*any* Compaq where you attempt to force an OS to use DMA when it is not selected
by the default install. Quite a few laptop clones are like the Compaq ( I had
a Twinheed one just a few weeks ago ). Desktop PCs can also be found with
iffy DMA hardware design. Beware the data corruption bug when shifting large
quantities of data between IDE ports on some chipsets, too. ( One range of
SiS chipsets suffered from this AFAIR ) Although IDE is a blocking type
device, the DMA behaviour can also vary from a single device per IDE port
to multiple devices daisy-chained on one IDE port. Had I decided to use a
cheaper IDE CD Burner on my SiS chipset Desktop ( 2001 Motherboard design )
I'd have walked right into the data corruption problem! ( I prefer to have at
least two separate hardware disk channels, one of them SCSI, for best VM
performance, anyway. ).
If you multiboot with Windows 9x ( perhaps to use Office 97 from Wine ) it
is easy to test. Make sure that the Windows boot comes to a real DOS prompt,
so you have to start Windows with WIN at the prompt ( edit MSDOS.SYS ). Make
COPIES of the registry SYSTEM.D* and USER.D* files! Then - in windows, play
with the DMA enables for the IDE Harddrive and CDROM. When windows fails to
load you have an answer... ( Restore the registry files, and it should be
OK ). I haven't known this to corrupt data on the drive, but I'm not making
any promises. The worst that usually happens is that it fails to load the
"DOS extender" <*grin*>
Try this with Linux, and you will probably trash the filesystem. A disposable
Windows test multiboot can be a less shattering test option to determine if
your machine has well behaved DMA hardware! But there are no guarantees if
you start tweaking hardware related stuff. ( Overclocking is another example ).
Eventually, you will reach a point where the probability of a timing error
will corrupt data, as timing margins are reduced.
Consider that slower disk performance means a higher safety margin against
data corruption. The size of IDE hard drives now is such that there is a
reasonable statistical likelihood of hitting random data corruption, anyway.
To reply by private email DONT delete the "nospam" in
Reply To or From header addresses!
More information about the main