cyosta@taux01.UUCP (Yossie Silverman) (10/22/88)
I am trying to find out how fast my HD is compared to others. Anyway, it is
about time for another disk speed survey. Send the three numbers that
DiskTimer II provides to me and I will summerize to the net in a week or
two. Send the following information:
Machine type(128,512,512e,+,SE,II,IIx specifying optional SCSI board,
accelerator).
Disk brand name, size, any other relavent information.
System being used and relavent patches.
Thanks.
My network address is: taux01!cyosta@nsc.UUCP
--
Yossie Silverman What did the Caspian sea?
National Semiconductor Ltd. (Israel) - Saki
UUCP: taux01!yossie@nsc.UUCP
NSA LSD FBI KGB PCP CIA MOSAD NUCLEAR MI5 SPY ASSASSINATE SDI -- OOCLAY ITAYalexis@ccnysci.UUCP (Alexis Rosen) (10/23/88)
I suggest that if you want to get really good numbers, we should all use
SCSI Evaluator instead of DiskTimer II. It corrects many flaws in DiskTimer
II's methodology, and I am not aware of any problems with it.
----
Alexis Rosen alexis@dasys1.UUCP or alexis@ccnysci.UUCP
Writing from {allegra,philabs,cmcl2}!phri\
The Big Electric Cat uunet!dasys1!alexis
Public UNIX {portal,well,sun}!hoptoad/lad@eplrx7.UUCP (lad) (10/24/88)
From article <910@taux01.UUCP>, by cyosta@taux01.UUCP (Yossie Silverman): > I am trying to find out how fast my HD is compared to others. Anyway, it is > about time for another disk speed survey. Send the three numbers that > DiskTimer II provides to me and I will summerize to the net in a week or > two. Send the following information: If you're looking to compare the performance of SCSI disks Disktimer is NOT the way to do it. Disktimer is not a benchmark, it favors disks with a 1:1 interleave and it's results do not reflect real-world disk performance. Supermac based their whole marketing scheme around Disktimer, saying their disks were faster because Disktimer said so. If you want to fairly evaluate SCSI disk performance use SCSI Evaluator. It dosen't play favorites and you can trust the data it comes up with, to a point. -- Lawrence A. Deleski | E.I. Dupont Co. uunet!eplrx7!lad | Engineering Physics Lab Cash-We-Serve 76127,104 | Wilmington, Delaware 19898 MABELL: (302) 695-9353 | Mail Stop: E357-302
pgn@osupyr.mast.ohio-state.edu (Paul G. Nevai) (10/27/88)
Where can I get "SCSI Evaluator"? Paul Nevai pgn@osupyr.mast.ohio-state.edu Department of Mathematics TS1171@ohstvma.BITNET The Ohio State University 73057,172.Compu$erve Columbus, OH 43210 1-(614)-292-5310.office U.S.A. 1-(614)-292-4975.secy
cyosta@taux01.UUCP (Yossie Silverman) (10/30/88)
In article <945@ccnysci.UUCP> alexis@ccnysci.UUCP (Alexis Rosen) writes: > >I suggest that if you want to get really good numbers, we should all use >SCSI Evaluator instead of DiskTimer II. It corrects many flaws in DiskTimer >II's methodology, and I am not aware of any problems with it. > >---- I'm game. Can you post it? If it's not too big I would prefer that you posted it directely to this group rather than to the comp.binaries.mac group as it will arrive a few months earlier.. I will still collect the DiskTimer II results and publish them. If results from this new program start flowing in within a week, I will delay for two extra weeks and publish them all at once. As a side note. Please don't expect personal replies from me to your letters as my mailer is VERY brain damaged. It rarely reaches anyone (except, lucky me, news). If it's very important, mail it to RPR1YOS@TECHNION.BITNET and I will try to answer from there (slower). -- Yossie Silverman What did the Caspian sea? National Semiconductor Ltd. (Israel) - Saki UUCP: taux01!yossie@nsc.UUCP NSA LSD FBI KGB PCP CIA MOSAD NUCLEAR MI5 SPY ASSASSINATE SDI -- OOCLAY ITAY
rampil@cca.ucsf.edu (Ira Rampil) (10/31/88)
In article <16@eplrx7.UUCP> lad@eplrx7.UUCP (lad) writes: > >If you're looking to compare the performance of SCSI disks Disktimer is NOT the way to >do it. Disktimer is not a benchmark, it favors disks with a 1:1 interleave and it's >results do not reflect real-world disk performance. Supermac based their whole >marketing scheme around Disktimer, saying their disks were faster because Disktimer >said so. > >-- > Lawrence A. Deleski | E.I. Dupont Co. Could it be that DiskTimer favors 1:1 interleave disks because they ARE faster? Is this in dispute? Ira Rampil Department of Anesthesia UCSF #include null_disclaimer.h
lad@eplrx7.UUCP (lad) (11/02/88)
From article <1449@ucsfcca.ucsf.edu>, by rampil@cca.ucsf.edu (Ira Rampil): > In article <16@eplrx7.UUCP> lad@eplrx7.UUCP (lad) writes: >> >>If you're looking to compare the performance of SCSI disks Disktimer is NOT the way to >>do it. Disktimer is not a benchmark, it favors disks with a 1:1 interleave and it's >>results do not reflect real-world disk performance. Supermac based their whole >>marketing scheme around Disktimer, saying their disks were faster because Disktimer >>said so. >> >>-- >> Lawrence A. Deleski | E.I. Dupont Co. > > Could it be that DiskTimer favors 1:1 interleave disks because > they ARE faster? Is this in dispute? 1:1 disks are faster only if the machine they're working on supports 1:1. For example, Apple claims that a 3:1 interleave is optimal for a Mac Plus, so a disk formatted to 1:1 is going perform slower. Disktimer's problem is that it totally bypassed the driver and made calls directly to the low-level SCSI routines, totally ignoring the OS. Any disk with a 1:1 interleave performed better in Disktimer no matter what machine it was being run on. There are several other reasons why Disktimer should not be seriously considered when evaluating SCSI disk performance, but they are very technical in nature. Disktimer II: Just say NO. Lawrence A. Deleski | E.I. Dupont Co. uunet!eplrx7!lad | Engineering Physics Lab Cash-We-Serve 76127,104 | Wilmington, Delaware 19898 MABELL: (302) 695-9353 | Mail Stop: E357-302 -- Lawrence A. Deleski | E.I. Dupont Co. uunet!eplrx7!lad | Engineering Physics Lab Cash-We-Serve 76127,104 | Wilmington, Delaware 19898 MABELL: (302) 695-9353 | Mail Stop: E357-302
ephraim@think.COM (Ephraim Vishniac) (11/03/88)
In article <29@eplrx7.UUCP> lad@eplrx7.UUCP (lad) writes: >From article <1449@ucsfcca.ucsf.edu>, by rampil@cca.ucsf.edu (Ira Rampil): >> In article <16@eplrx7.UUCP> lad@eplrx7.UUCP (lad) writes: >>>If you're looking to compare the performance of SCSI disks >>>Disktimer is NOT the way to do it. Disktimer is not a benchmark, >>>it favors disks with a 1:1 interleave and it's results do not >>>reflect real-world disk performance. Supermac based their whole >>>marketing scheme around Disktimer, saying their disks were faster >>>because Disktimer said so. >>> Lawrence A. Deleski | E.I. Dupont Co. >> Could it be that DiskTimer favors 1:1 interleave disks because >> they ARE faster? Is this in dispute? >1:1 disks are faster only if the machine they're working on supports >1:1. For example, Apple claims that a 3:1 interleave is optimal for >a Mac Plus, so a disk formatted to 1:1 is going perform slower. >Disktimer's problem is that it totally bypassed the driver and made >calls directly to the low-level SCSI routines, totally ignoring the >OS. Any disk with a 1:1 interleave performed better in Disktimer no >matter what machine it was being run on. There are several other >reasons why Disktimer should not be seriously considered when >evaluating SCSI disk performance, but they are very technical in >nature. >Disktimer II: Just say NO. Time to stop the garbage, Larry. DiskTimer *does not* bypass the driver. DiskTimer calls the disk's driver through the Device Manager. That's what the Mac file system does, and that's why DiskTimer's results have some bearing on the performance that a disk makes available to the file system. DiskTimer *agrees* with what Apple *actually* claimed, which is that a Seagate ST225N on a MacPlus with Apple's driver is optimally interleaved at 3:1. If your disk or driver or Mac is different, then Apple's advice is perfectly irrelevant. It's also untrue that making calls "directly to the low-level SCSI routines" (which are part of the OS) gives you the best transfer rates with 1:1 interleaving. This is what the disk drivers do, after all, and that's not the result they get! I'm amazed that you continue to spout this nonsense. Just within the past month, there were a series of articles here (comp.sys.mac) discussing how someone mistakenly formatted his disk at 1:1 instead of 2:1 and got dismal performance -- plainly shown by DiskTimer! Try some tests yourself, Larry. You'll find your foot's been in your mouth for a long time. Ephraim Vishniac ephraim@think.com Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142-1214 On two occasions I have been asked, "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?"
straka@ihlpf.ATT.COM (Straka) (11/04/88)
In article <29@eplrx7.UUCP> lad@eplrx7.UUCP (lad) writes: >From article <1449@ucsfcca.ucsf.edu>, by rampil@cca.ucsf.edu (Ira Rampil): >> In article <16@eplrx7.UUCP> lad@eplrx7.UUCP (lad) writes: ||| ||| If you're looking to compare the performance of SCSI ||| disks Disktimer is NOT the way to do it. Disktimer is ||| not a benchmark, it favors disks with a 1:1 interleave ||| and it's results do not reflect real-world disk ||| performance. Supermac based their whole marketing ||| scheme around Disktimer, saying their disks were ||| faster because Disktimer said so. ||| Lawrence A. Deleski | E.I. Dupont Co. || Could it be that DiskTimer favors 1:1 interleave disks because || they ARE faster? Is this in dispute? | 1:1 disks are faster only if the machine they're working on | supports 1:1. For example, Apple claims that a 3:1 | interleave is optimal for a Mac Plus, so a disk formatted | to 1:1 is going perform slower. Disktimer's problem is that | it totally bypassed the driver and made calls directly to | the low-level SCSI routines, totally ignoring the OS. Any | disk with a 1:1 interleave performed better in Disktimer no | matter what machine it was being run on. There are several | other reasons why Disktimer should not be seriously | considered when evaluating SCSI disk performance, but they | are very technical in nature. If the disk controller that is used has implemented sufficient buffering to store a track's worth of data as a sector cache, running a 1:1 interleave CAN result in increased data transfer rate regardless of the Mac that the disk is hung off of. Only ONE rotation is required for the track, period. The Mac then takes the data from the controller's buffer at the max data rate. As I recall, the OMTI 31xx controller (from SMS, their parent company) that SuperMac used in their XP series had such buffering so that 1:1 would work efficiently (read full-tilt) on ANY Mac without reformatting. THAT was their marketing strategy. Before making blanket statements like that above, please make sure that all the facts are out on the table. May I assume that you have detailed facts to back up your claims? Standard Disclaimer: I have no financial interest in SuperMac, SMS, Micah, Apple, or any other company associated with this discussion except as an occasional customer. I additionally have no particular opinion on DiskTimer IIa, or whatever, except that I want the best information all on the table. -- Rich Straka att!ihlpf!straka Avoid BrainDamage: MSDOS - just say no!
lad@eplrx7.UUCP (lad) (11/04/88)
From article <30248@think.UUCP>, by ephraim@think.COM (Ephraim Vishniac): > > Time to stop the garbage, Larry. DiskTimer *does not* bypass the > driver. DiskTimer calls the disk's driver through the Device Manager. > That's what the Mac file system does, and that's why DiskTimer's > results have some bearing on the performance that a disk makes > available to the file system. DiskTimer *agrees* with what Apple > *actually* claimed, which is that a Seagate ST225N on a MacPlus with > Apple's driver is optimally interleaved at 3:1. If your disk or > driver or Mac is different, then Apple's advice is perfectly > irrelevant. Nice try. The previous statements completely contradict all that's ever been said about Disktimer. Disktimer NEVER used the Device Manager, and it NEVER used the File Manager, something ALL drivers have to do to talk to the disk. > I'm amazed that you continue to spout this nonsense. Why the personal attacks? Nonsense is exactly what this is. >Just within the > past month, there were a series of articles here (comp.sys.mac) > discussing how someone mistakenly formatted his disk at 1:1 instead of > 2:1 and got dismal performance -- plainly shown by DiskTimer! I read those articles but they have nothing to do with what we're talking about here. I'm talking about real tests done by real people on real disks, which, by the way, were formatted at 1:1, 2:1, and 3:1. Disktimer consistantly favored disks formatted 1:1 no matter which machine they're run on. What's nonsense is how you continue to praise Disktimer as a real performance benchmark. > > Try some tests yourself, Larry. You'll find your foot's been in your > mouth for a long time. Not so, Ehpraim. I don't know what your problem is, but Disktimer is bogus and many people have known about it for a long time. I *have* run tests, and came to the same conclusions that Jim Reeks and many others came to, Disktimer has little or no bearing on disk performance. By the way, you forget too easily that Reeks did extensive testing and even published an article on Disktimer. I'm going to track it down and post it to the net. I remember you flaming Reeks about that article, using the same arguments you're using now. Those arguments were wrong then, and they're wrong now. Steve Brecher has even said many times before that Disktimer, the program *he* wrote, dosen't reflect real-world disk performance. It's even in the program's initial screen!! You stop the garbage, Ephraim. It's seems you have some vested interest in seeing that Disktimer somehow succeeds. I wish you luck. -- Lawrence A. Deleski | E.I. Dupont Co. uunet!eplrx7!lad | Engineering Physics Lab Cash-We-Serve 76127,104 | Wilmington, Delaware 19898 MABELL: (302) 695-9353 | Mail Stop: E357-302
ephraim@think.COM (Ephraim Vishniac) (11/05/88)
In article <29@eplrx7.UUCP> lad@eplrx7.UUCP (lad) writes: >From article <1449@ucsfcca.ucsf.edu>, by rampil@cca.ucsf.edu (Ira Rampil): >> In article <16@eplrx7.UUCP> lad@eplrx7.UUCP (lad) writes: >>>If you're looking to compare the performance of SCSI disks >>>Disktimer is NOT the way to do it. Disktimer is not a benchmark, >>>it favors disks with a 1:1 interleave and it's results do not >>>reflect real-world disk performance. Supermac based their whole >>>marketing scheme around Disktimer, saying their disks were faster >>>because Disktimer said so. >> Could it be that DiskTimer favors 1:1 interleave disks because >> they ARE faster? Is this in dispute? >1:1 disks are faster only if the machine they're working on supports >1:1. For example, Apple claims that a 3:1 interleave is optimal for >a Mac Plus, so a disk formatted to 1:1 is going perform slower. >Disktimer's problem is that it totally bypassed the driver and made >calls directly to the low-level SCSI routines, totally ignoring the >OS. Any disk with a 1:1 interleave performed better in Disktimer no >matter what machine it was being run on. There are several other >reasons why Disktimer should not be seriously considered when >evaluating SCSI disk performance, but they are very technical in >nature. >Disktimer II: Just say NO. > Lawrence A. Deleski | E.I. Dupont Co. Larry has pointed out to me in private correspondence that my initial response was inappropriately worded. He's entirely correct in that respect, and I apologize. If ever I feel the need to insult Larry in the future, I'll take care to do it privately. That said, I'd like to correct some factual errors in Larry's posting and explain my view of disk benchmarking. DiskTimer II does not bypass the device driver. It does not use the SCSI manager traps or touch the SCSI hardware directly. Instead, it calls the device driver via the device manager. (This should be obvious from the fact that it works on non-SCSI devices. If you have any doubts, you can read the publicly available source code.) Since this what the file manager does, this is the basis for any resemblance between DiskTimer's results and actual system performance. Apple did not simply claim that a 3:1 interleave is optimal for a Mac Plus. They claimed that a 3:1 interleave is optimal for a Seagate ST225N on a Mac Plus when the disk driver operates through the Apple-supplied SCSI manager. I've tested this claim using DiskTimer and similar programs and they agree with Apple. Provided that your disk driver uses the SCSI manager, Apple's advice is applicable to a particular class of drives: MFM drives without significant cache. If you're not using the SCSI manager (and many people don't) or if your drive is RLL, has a substantial cache or FIFO, then Apple's advice simply doesn't apply. Larry's claim about DiskTimer II using "low-level SCSI routines" fails to make sense in another way. The device drivers, after all, use the low-level SCSI routines or manipulate the hardware directly. If using the low-level routines gives the fastest data transfer rates with 1:1 interleaving, why don't the device drivers get that result? So far as I know, DiskTimer II's greatest failing is that it's trivially deceived by caching, either in the disk controller or in the device driver. SuperMac's claims relied on the former case; FWB's grossly misleading advertising depended on the latter case. I'm sure other companies made equally deceptive claims, but I didn't read all the ads. DiskTimer II repeatedly reads and writes the same 18K block. Any cache over 18K immediately gains a 100% hit rate and a spuriously good score. Obviously, this isn't realistic. Does SCSI Evaluator avoid this trap? I don't know. It does give you the opportunity to compare performance through the device driver against "raw" SCSI manager calls. I expect (though I don't know) that you'll find little advantage to the raw calls. With some disks, you'll find that the device driver has the advantage because it bypasses the SCSI manager. The greatest failing with all benchmarks is that it requires a great deal of thought and knowledge to make sense of the results and apply them to "the real world." DiskTimer II boils everything down to three numbers. I personally feel that the data transfer rates are of only modest importance of a fairly wide range. That's what the programmer can tweak, though, so that's where the hot competition is. In many Mac operations, such as launching an application, much of the time is spent seeking. Seek time is entirely up to the drive manufacturer. A remarkable number of "different" Mac drives have the same mechanisms inside, so there's little competition here. (BTW, DiskTimer II's seek test is also trivially defeated by caching.) As other posters have pointed out, SCSI Evaluator gives the user a great number of options and delivers a graph with numerous data points. If you're a developer tweaking your disk driver, or a user benchmarking a variety of drives at once, this is fantastic. If you're trying to compare notes with strangers via usenet, it's very nearly hopeless. Claimers and disclaimers: I have sold disk driver software to several companies, including Jasmine (San Francisco), Colby Systems (Fresno), DataSpace (Markham, Ontario), and others that never went anywhere. I'm out of that business now. Larry Deleski is (was? what's the latest, Larry?) a principal of IDT, which owns Micah. Ephraim Vishniac ephraim@think.com Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142-1214 On two occasions I have been asked, "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?"
ephraim@think.COM (Ephraim Vishniac) (11/07/88)
In article <31@eplrx7.UUCP> lad@eplrx7.UUCP (lad) writes: >Disktimer NEVER used the Device Manager, and it NEVER used the File >Manager, something ALL drivers have to do to talk to the disk. Read the source code. DiskTimer uses Read and Write calls. These are executed by the Device Manager, which selects the appropriate driver and calls it. Also, read Inside Mac. The File Manager uses the Device Manager uses the device drivers which use the SCSI manager or hardware. Claiming that the device drivers call the File Manager only shows that you've never read or written a device driver. >>Just within the >> past month, there were a series of articles here (comp.sys.mac) >> discussing how someone mistakenly formatted his disk at 1:1 instead of >> 2:1 and got dismal performance -- plainly shown by DiskTimer! >I read those articles but they have nothing to do with what we're >talking about here. I'm talking about real tests done by real people >on real disks, which, by the way, were formatted at 1:1, 2:1, and >3:1. Disktimer consistantly favored disks formatted 1:1 no matter >which machine they're run on. Could one of the people involved in that earlier discussion please speak up? Are you a real person? Are you a zombie? An android? An Alien Life Form? Did you run the tests on real disks or on imaginary ones? >What's nonsense is how you continue to praise Disktimer as a real >performance benchmark. I didn't, Larry. Calm yourself, and reread what I wrote. There's no praise of DiskTimer there, just criticism of your criticism. >By the way, you forget too easily that Reeks did extensive testing >and even published an article on Disktimer. I'm going to track it >down and post it to the net. I remember you flaming Reeks about that >article, using the same arguments you're using now. Those arguments >were wrong then, and they're wrong now. Of course I remember Jim Reekes' bizarre tirade. In it, he made such amazing claims as "the Mac file system only does single-sector transfers, so multi-sector transfers are irrelevant." >Steve Brecher has even said many times before that Disktimer, the >program *he* wrote, dosen't reflect real-world disk performance. >It's even in the program's initial screen!! I agree that DiskTimer's got problems. But the only way we'll get a better benchmark is through accurate, intelligent criticism. >You stop the garbage, Ephraim. It's seems you have some vested >interest in seeing that Disktimer somehow succeeds. I wish you luck. DiskTimer has already "succeeded," unfortunately - it's the most widely accepted benchmark of add-on storage for the Mac. My interest is in seeing that people understand its failings. And as one of Micah's owners you're perfectly disinterested, right? Ephraim Vishniac ephraim@think.com Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142-1214 On two occasions I have been asked, "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?"
md32+@andrew.cmu.edu (Michael Joseph Darweesh) (11/08/88)
Yea, Dont totally believe DiskTimer. It told me that it took 22 seconds for my drive to read the test packets 22 SECONDS!!!! The other figures were reasonable but the above psycho result has happened many times and I just ignore it. Sure, I have a 140MB HD, but it just doesnt take that long to write stuff Mike Darweesh Carnegie Mellon University
md32+@andrew.cmu.edu (Michael Joseph Darweesh) (11/08/88)
Sorry about the screwed up post right before this one. I meant (in every case stated) to say write to my hard drive not read. My read times were .5 times the sample data results. -Mike Darweesh -Carnegie Mellon University -md32+@andrew.cmu.edu
lad@eplrx7.UUCP (lad) (11/08/88)
From article <30582@think.UUCP>, by ephraim@think.COM (Ephraim Vishniac):
Lots of 'bizzare' things...
Ephraim, it's obvious that you beleive that you're right and everyone else
is wrong.
And for the record, I haven't owned any interest in Micah since Jan 27,
1988. It's a matter of public record. Call the State of Delaware Division
of Corporations at (302) 736-3133.
And finally, if you don't know the facts, check them out before you make
statements like that.
/lad
--
Lawrence A. Deleski | E.I. Dupont Co.
uunet!eplrx7!lad | Engineering Physics Lab
Cash-We-Serve 76127,104 | Wilmington, Delaware 19880-0357
MABELL: (302) 695-9353 | Mail Stop: E357-302rterry@hpcupt1.HP.COM (Ray Terry) (11/09/88)
Hey, guys... Nuff said, okay?? We get the idea...
How bout letting the whole thing drop and don't let it get your blood pressure
up. You'll live longer and enjoy it more...
:-)
Ray
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Ray Terry Hewlett Packard Company
GEnie : R.Terry MacNET: Ray
Packet: N6PHJ @ N6IIU UUCP : sun!hpda!hpcupt1!rterry
Domain: rterry%hpda@hplabs.hp.com SysOp : MacScience BBS (408) 247-8307
IPaddr: 44.4.0.214 N6PHJ.norcal.ampr
Standard disclaimers, etc. apply...
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-singer@endor.harvard.edu (Rich Siegel) (11/09/88)
In article <32@eplrx7.UUCP> lad@eplrx7.UUCP (lad) writes: >From article <30582@think.UUCP>, by ephraim@think.COM (Ephraim Vishniac): > >Lots of 'bizzare' things... > A quote calling someone else's post 'bizarre' without ANY rebuttal tends to not cut any ice with me. What makes it bizarre, beyond the fact that you can't seem to formulate a coherent response to it? > >And finally, if you don't know the facts, check them out before you make >statements like that. This is advice that you would be well-advised to take. --Rich Rich Siegel Staff Software Developer THINK Technologies Division, Symantec Corp. Internet: singer@endor.harvard.edu UUCP: ..harvard!endor!singer Phone: (617) 275-4800 x305 Any opinions stated in this article do not necessarily reflect the views or policies of Symantec Corporation or its employees.
ts@cup.portal.com (Tim W Smith) (11/23/88)
Note that many disks ignore interleave. For instance, Quantum ProDrive disks are always 1:1. I think CDC Wren IVs might be that way too, but the manual does not seem to be within sight at the moment ( I gotta clean out this office :-) ). Tim Smith