----- Original Message -----
From: <SUPRDAVE_at_aol.com>
To: <classiccmp_at_classiccmp.org>
Sent: Wednesday, May 24, 2000 9:13 PM
Subject: Re: Bootable Floppy from CD?
> In a message dated 5/24/00 10:05:16 PM Eastern Daylight Time,
> richard_at_idcomm.com writes:
<snip>
> > DOS, yet the maintenance tools (scandisk) seem to work better on
compressed
> > volumes than on uncompressed. Compression does seem to enhance disk
> > subsystem preformance. If you have a solid backup regimen, you should
> never
> > have to worry about data loss just because you use compression. I
found
> > that DRVSPACE yielded about a 15% performance increase and had no added
> risk
> > of system failure. I also found that the risk of data loss was
actually
> > lower (based on my substantial but still relatively small data sample)
> than
> > that with uncompressed data, probably due to the more effective error
> > management tools.
> >
> I use pcdos 6.3 and 7.0. much better than msdos i think, and i prefer the
> editor. how in the world can one realise 15% performance increase running
> disk compression? logic would indicate a degradation since you are running
an
> extra task to compress the hard drive not to mention less memory space in
the
> UMBs to load the compression driver high. i do not use any sort of disk
> compression and never recommend it to anyone. i supported end users, and
> there were too many times when users compressed their hard drives, and
ended
> up hosing them. only option to them was fdisk and reinstall. K.I.S.S.
>
> DB Young ICQ: 29427634
>
> hurry, hurry, step right up! see the computers you used as a kid!
> http://members.aol.com/suprdave/classiccmp/museum.htm
>
>
The way in which the disk subsystem produces a performance increase is quite
simple. With nominal 2x (just to make the numbers easy) compression, the
platter holds 2x as much data, which means that on average, a given track
holds twice the data, hence, there are half as many seeks required in
transfer of a given amount of data.
A seek even for one cylinder, takes milliseconds, not the relatively few
microseconds required to decompress a buffer full of data, which the system
does on the fly. So, if you have to transfer 512KB of data, once, you won't
see much difference, but if you have to execute a task which requires you to
look at, say, 20 MB of data, over the course of which you have to make 40
average seeks when you're operating without compression, you'd ostensibly
have to make half as many seeks because, in reality when you move 20 MB of
compressed data, you really have to move only 10 MB of data, and, on average
that will require half as many seeks.
If an average seek for your drive is, say 8 ms, which is a reasonably fast
drive, then instead of 320 milliseconds, you'll only use 160 for 20 average
seeks, and, by the way, the time used to move that data is negligible next
to the time, orders of magnitude more, that is used moving the heads and
waiting for the platter to rotate in to the appropriate position.
Today's processors are many hundreds if not a few thousands of times faster
than the mechanical system on your disk drives. Moving the heads takes time
in the milliseconds, i.e. thousands of microseconds, while the decompression
algorithm is done by the otherwise idle processor (remember what software
we're using !) that's executing instructions in a few tens of nanoseconds.
The CPU works in parallel with the intelligence on the drive to accomplish
the decompression. It's still idle or waiting for the drive 90% of the
time.
You're right in that it makes for more complex I/O and file management code,
but it's just a drop in the bucket, and it's a drop that increases the
rotating memory subsystem performance significantly.
Dick
Received on Wed May 24 2000 - 23:30:44 BST