ephraim@wang7.UUCP (ephraim) (08/25/87)
I am discussing with Steve Brecher the creation of a new version of DiskTimer (DT III) to avoid or reduce certain problems with DiskTimer II's measurements of disk performance. At his suggestion, I'm taking the discussion public with this request for comments. Please mail responses to decvax!masscomp!wang7!ephraim (if you can), MASSTECH on MCI mail (if that's easier for you), or Ephraim Vishniac / P.O. Box 1357 / East Arlington, MA 02174 if e-mail just doesn't do it for you. Please understand that DiskTimer III is intended to be in the same general vein as DiskTimer II. That is, it will be a non-destructive test of a disk drive's data transfer rate measured at the driver interface. It will not be a test of system performance, so correlation with a user's expectation of performance will continue to be problematic. ---------Start of technical stuff----------- DiskTimer II attempts to measure the data transfer rate of a disk drive under optimal conditions, i.e., with a minimum of head and cylinder crossings. To do so, it makes elaborate efforts to locate a region of the disk which presents the least data transfer time, then makes repeated measurents of read/write times in that region. There are (at least) two failings in this approach. First, this optimal case is not typical. Files are not placed with respect to tracks or cylinders, so their boundaries will often be crossed in the course of a single I/O operation. Of course, if DiskTimer tested a single region without the precautions that it now takes, drives which happened to seek in that region would be unfairly penalized. Second, this approach fails completely to measure data transfer time when the driver incorporates a local cache. Since the same region is read and written repeatedly, DiskTimer II presents an optimal caching situation. This is the cause of the ridiculous results that one vendor was touting in sales literature at the Boston MacWorld show. The major feature of DiskTimer III is a change in approach that avoids both of the above problems. Rather than read/write the same area 100 times, DT III will read/write consecutive areas of the disk. So, track and cylinder crossings will be represented in their native proportions. With respect to caching, the test will be pessimal instead of optimal. Since the test is for raw data transfer rate, this is exactly as it should be. To be more precise about the test sequence, DT III will: read CurrentTestSector - 1 into TrashBuffer dither-with-respect-to-system-tick-and-disk-rotation start ReadTimer read 24K at CurrentTestSector into DataBuffer stop ReadTimer read CurrentTestSector - 1 into TrashBuffer dither-with-respect-to-system-tick-and-disk-rotation start WriteTimer write 24K at CurrentTestSector from DataBuffer stop WriteTimer advance CurrentTestSector by 24K/SectorSize for a total of 100 reads and 100 writes. Of course, there will be tests to avoid running off the end of the volume, to stop on I/O errors, etc. The same general idea will be used on the Seek portion of the benchmark, to insure that the drive really does seek instead of returning cached data. Minor new features of DiskTimer III will include: reporting the disk driver's name, icon, and 'where' string reporting the system version, ROM version, and CPU type user selection of the volume to test if SCSI drive, report Vendor ID and Product ID from SCSI Inquiry Since DiskTimer III results will not be directly comparable to DT II results, there will be a new scale. So: What problems am I introducing? What other problems should I address? -----------End of technical stuff---------- -- Ephraim Vishniac masscomp!wang7!ephraim