24 May
2000
24 May
'00
6:13 p.m.
In a message dated 5/24/00 10:05:16 PM Eastern Daylight Time,
richard(a)idcomm.com writes:
I've never encountered that version 6.3. I've
got a few sets of install
disketted for DOS 6.21, which was made up for DELL, specifically without
the
compression support in it or among its utilities. I,
havning spent much
time testing the more popular compression schemes, am an avid user of
compression. I've found it to be no more problem-prone than plain-vanilla
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
24 May
24 May
7:30 p.m.
----- Original Message -----
From: <SUPRDAVE(a)aol.com>
To: <classiccmp(a)classiccmp.org>
Sent: Wednesday, May 24, 2000 9:13 PM
Subject: Re: Bootable Floppy from CD?
found
actually
an
In a message dated 5/24/00 10:05:16 PM Eastern
Daylight Time,
richard(a)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 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 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 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
7:52 p.m.
On Wed, May 24, 2000 at 11:13:24PM -0400, SUPRDAVE(a)aol.com wrote:
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 have trouble buying this too, but if the CPU and disk drive speed are
totally out of whack with one another, the disk could be so slow that the
CPU can inflate N KB of data to 2*N KB faster than the disk can read 2*N KB
of uncompressed data.
Anyway IBM is still in the DOS business, and I gotta respect them just
for that! The latest flavor I know of is "PC DOS 2000", nice to see some
recent work being done, even if they re-used the previous documentation
(it's a PC DOS 7 manual with a sticker on the front that says PC DOS 2000).
John Wilson
D Bit
7:55 p.m.
So, does this PCDOS 2000 have any useful characteristics that MSDOS lacks?
Dick
----- Original Message -----
From: John Wilson <wilson(a)dbit.dbit.com>
To: <classiccmp(a)classiccmp.org>
Sent: Wednesday, May 24, 2000 10:52 PM
Subject: Re: Bootable Floppy from CD?
KB
On Wed, May 24, 2000 at 11:13:24PM -0400,
SUPRDAVE(a)aol.com wrote:
> 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 have trouble buying this too, but if the CPU and disk drive speed are
totally out of whack with one another, the disk could be so slow that the
CPU can inflate N KB of data to 2*N KB faster than the disk can read 2*N of uncompressed data.
Anyway IBM is still in the DOS business, and I gotta respect them just
for that! The latest flavor I know of is "PC DOS 2000", nice to see some
recent work being done, even if they re-used the previous documentation
(it's a PC DOS 7 manual with a sticker on the front that says PC DOS
2000).
John Wilson
D Bit
25 May
25 May
1:54 a.m.
New subject: PCDOS 2000
On Wed, May 24, 2000 at 11:13:24PM -0400,
SUPRDAVE(a)aol.com wrote:
I think PCDOS 2000 would've just been PCDOS 7.1 if it wasn't for the y2k
marketing fever.
It's interesting that they've been using the Ramboost from Central Point
Software in it years after CPS got swallowed and eradicated by Symantec.
Bill
--
bpechter(a)monmouth.com | Microsoft: Where do you want to go today?
| Linux: Where do you want to go tomorrow?
| BSD: Are you guys coming, or what?
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 have trouble buying this too, but if the CPU and disk drive speed are
totally out of whack with one another, the disk could be so slow that the
CPU can inflate N KB of data to 2*N KB faster than the disk can read 2*N KB
of uncompressed data.
Anyway IBM is still in the DOS business, and I gotta respect them just
for that! The latest flavor I know of is "PC DOS 2000", nice to see some
recent work being done, even if they re-used the previous documentation
(it's a PC DOS 7 manual with a sticker on the front that says PC DOS 2000).
John Wilson
D Bit
8:47 a.m.
New subject: PCDOS 2000
On Thu, May 25, 2000 at 06:54:41AM -0400, Bill Pechter wrote:
It's interesting that they've been using the
Ramboost from Central Point
Software in it years after CPS got swallowed and eradicated by Symantec.
So *that's* what happened to CPS! I've been using the CPBACKUP that came
with PC-DOS (6.3?) for years, but a while back when I went looking to buy the
latest version (if any), I couldn't find any trace of CPS. Well I guess the
fact that they don't exist any more doesn't let them off the hook with their
agreement with IBM!!! CPBACKUP is still there, and so is CP UNDELETE.
John Wilson
D Bit
10:29 a.m.
New subject: PCDOS 2000
On Thu, 25 May 2000, John Wilson wrote:
On Thu, May 25, 2000 at 06:54:41AM -0400, Bill Pechter
wrote:
And that is what happened to the CPS Deluxe Option Card and the earlier
Copy-to-PC software, also.
- don
It's interesting that they've been using
the Ramboost from Central Point
Software in it years after CPS got swallowed and eradicated by Symantec.
So *that's* what happened to CPS! I've been using the CPBACKUP that came
with PC-DOS (6.3?) for years, but a while back when I went looking to buy the
latest version (if any), I couldn't find any trace of CPS. Well I guess the
fact that they don't exist any more doesn't let them off the hook with their
agreement with IBM!!! CPBACKUP is still there, and so is CP UNDELETE.
John Wilson
D Bit
10:56 a.m.
New subject: PCDOS 2000
On Thu, May 25, 2000 at 06:54:41AM -0400, Bill Pechter
wrote:
Surprised you didn't hear that.
I was so mad I swore I wouldn't buy Norton* after that because
the support dropped too quickly and they didn't pick the best programs
to keep -- PC Tools for Windows got subsumed to the Norton Equivalents.
Nothing beat the older PC Tools.
Symantec's website seems to have some updates for the PCTools stuff.
I assume IBM got source.
Of course when I worked for IBM I ordered their AntiVirus suite...
Paid the support fee -- then IBM drops the program and unloades it to
be the base of Norton AntiVirus.
Figures.
And DEC unloads the PDP11 to Mentec and OS/2 gets killed.
So it goes.
BTW -- Thanks again for E11.
Bill
--
bpechter(a)monmouth.com | Microsoft: Where do you want to go today?
| Linux: Where do you want to go tomorrow?
| BSD: Are you guys coming, or what?
It's interesting that they've been using
the Ramboost from Central Point
Software in it years after CPS got swallowed and eradicated by Symantec.
So *that's* what happened to CPS! I've been using the CPBACKUP that came
with PC-DOS (6.3?) for years, but a while back when I went looking to buy the
latest version (if any), I couldn't find any trace of CPS. Well I guess the
fact that they don't exist any more doesn't let them off the hook with their
agreement with IBM!!! CPBACKUP is still there, and so is CP UNDELETE.
John Wilson
D Bit
11:27 a.m.
New subject: Epson TF-10 Floppy Drive power
Does anyone have documentation or experience enough to describe the
battery power circuit for this external 3.5" floppy drive as used with
the PX-8 Geneva?
From the multiple terminals in the battery compartment,
it appears that
it must require an adapter of some sort to use and charge NiCads in
it,
whereas normal C cells just snap in and are isolated from the charging
circuit.
Any information appreciated.
- don
11:54 a.m.
New subject: PCDOS 2000
On Thu, May 25, 2000 at 03:56:22PM -0400, Bill Pechter wrote:
And DEC unloads the PDP11 to Mentec and OS/2 gets
killed.
Last I heard OS/2 was still very much alive, although IBM's attitude
towards it is surly to say the least. But unlike some companies I could
mention, IBM knows better than to refuse to accept money from their customers
just because the customers want to buy something other than whatever new
toy the IBM management is excited about this week. So it will probably
keep getting *some* support as long as the customers are willing to pay
for it.
John Wilson
D Bit
7 a.m.
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.
As usual, with disk compression YMMV. It depends upon where the bottleneck
is. The first system I used compressed volumes on (a long time back) had
an XT bus running at half the processor speed that was lucky to get 250 kBps
from the HD drives. It was so slow that the best
interleave was 1 because
it took an entire rotation to transfer one sector from the
controller to
memory. Compression besically doubled the I/O speed. A good (not smartdrive)
write cache (with write delay set to the max) worked wonders as well.
Even on my 386 machine compression turned out to be a performance boost in
DOS and Windows. In the end, I don't think I lost any data to failure of a
compressed drive. Stacker was pretty robust.
Eric
8819
days inactive
8820
days old
10 comments
6 participants
participants (6)
-
donm＠cts.com -
korpela＠albert.ssl.berkeley.edu -
pechter＠pechter.dyndns.org -
richard＠idcomm.com -
SUPRDAVE＠aol.com -
wilson＠dbit.dbit.com