Ritzert@DMZRZU71.BITNET (02/23/90)
Chris Ridd wrote: >I tried the RateHD a day or so ago >... >time was only about 36ms! Has DLII (the defragger used) done something >unexpected to my drive, or has RateHD gone doolally? RateHD is buggy. The results for the access time can be considered only a *rough* estimate. I found out that there is even a dependence on the partition size. Michael Ritzert mjr@dmzrzu71.bitnet
fischer-michael@CS.YALE.EDU (Michael Fischer) (02/24/90)
In article <900223121113.363135@DMZRZU71-UNI-MAINZ--GERMANY> Ritzert@DMZRZU71.BITNET writes: >Chris Ridd wrote: > >>I tried the RateHD a day or so ago >>... >>time was only about 36ms! Has DLII (the defragger used) done something >>unexpected to my drive, or has RateHD gone doolally? > >RateHD is buggy. The results for the access time can be considered only >a *rough* estimate. I found out that there is even a dependence on the >partition size. > Access time is seek time plus rotational delay. I don't know exactly what RadtHD is measuring, but the larger the partition, the further the head has to move to get from one end of the partition to the other, so it only stands to reason that the average access time should increase. This is hardly a reason to call a program buggy. This only points out the fact that overall disk performance can't be adequately measured by a single number -- it's very dependent on exactly what you are doing. RateHD measures the disk under one set of assumptions. Your mileage may vary. ================================================== | Michael Fischer | | Arpanet: <fischer-michael@cs.yale.edu> | | Bitnet: <fischer-michael@yalecs.bitnet> | | UUCP: <fischer-michael@yale.UUCP> | ==================================================
Ritzert@DMZRZU71.BITNET (02/26/90)
>>RateHD is buggy. The results for the access time can be considered only >>a *rough* estimate. I found out that there is even a dependence on the >>partition size. >> >Access time is seek time plus rotational delay. I don't know exactly >what RadtHD is measuring, but the larger the partition, the further the >head has to move to get from one end of the partition to the other, so >it only stands to reason that the average access time should increase. >This is hardly a reason to call a program buggy. But on a Seagate st296n with supra hostadapter, ratehd gave slower access time on smaller partitions (and on larger partitions than 16 M). In fact the difference to the manufacturer's specification seemed to be smallest on a 16 Meg partition. I don't demand that ratehd reprodueces the original spec; the readme file coming with ratehd states that this cannot be expected. But, anyhow, I'm astonished about that *strange* dependence which is not directly related to an obvious feature like the number of cylinders which have to be passed by the head(s). And don't forget that ICD claims measuring the drive independent on the way it is formatted. In this light, any dependence like the above has to be regarded a bug. M.Ritzert mjr@dmzrzu71.bitnet
logic@wet.UUCP (Henry Kwan) (03/10/90)
In article <16969@cs.yale.edu> fischer-michael@CS.YALE.EDU (Michael Fischer) writes: > >Access time is seek time plus rotational delay. I don't know exactly >what RadtHD is measuring, but the larger the partition, the further the >head has to move to get from one end of the partition to the other, so >it only stands to reason that the average access time should increase. >This is hardly a reason to call a program buggy. > Actually, there are a few other factors besides seek time and latency when computing access time. These include command overhead, head settling time, and a few other things which escape me at the moment. In any event, I believe that ICD states in their documentation that RateHD seeks 50 times from sector 0 to 31,999. Then timing is computed and a figure is spat out. So partition size shouldn't play a part in the computing of the average seek figure. (FYI, RateHD gave my Wren V a 19 ms rating and the manufacturer specs says that it is 18 ms. Coming to within 6% of the manufacturer's specs is pretty good in my book.) -- Henry Kwan | AppleLink: D0690 FWB, Inc. | CompuServe: 71320,1034 2040 Polk St. Ste 215 | Internet: claris!wet!logic@ames.arc.nasa.gov San Francisco, CA 94109 | UUCP: {claris,hoptoad,lamc,ucsfcca}!wet!logic
Ritzert@DMZRZU71.BITNET (03/22/90)
Subject: ICD RateHD Message-ID: <6177@umd5.umd.edu> >In article <9002212030.aa00488@benjamin.Cs.Bham.AC.UK> > RiddCJ@computer-science.birmingham.ac.UK (Chris Ridd) writes: >[stuff deleted for inews's sake] >>my root partition (only about 4Megs) and ran it again. This time, the access >>time was only about 36ms! Has DLII (the defragger used) done something >>unexpected to my drive, or has RateHD gone doolally? >> >>-- Chris Ridd, Computer Science, Birmingham Uni, UK -- RiddCJ@Cs.Bham.Ac.Uk -- This confirms an observation of mine which I reported on Usenet and a lot of people didn't want to believe me... Calling such a behaviour "buggy" (as I did) or "not always constant" describes only a different attitude toward it. Michael Ritzert mjr@dmzrzu71.bitnet A feature is a bug that is documented. (ws)