Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!apollo!goykhman_a
From: goykhman_a@apollo.HP.COM (Alex Goykhman)
Newsgroups: comp.periphs.scsi
Subject: Re: <8141517@lehtori.cc.tut.fi>
Message-ID: <51220071.20b6d@apollo.HP.COM>
Date: 22 Apr 91 22:19 GMT
References: <8141517@lehtori.cc.tut.fi> <283400095@adaptx1>
Sender: root@apollo.HP.COM
Reply-To: goykhman_a@apollo.HP.COM (Alex Goykhman)
Organization: Hewlett-Packard Apollo Division - Chelmsford, MA
Lines: 79

In article <283400095@adaptx1> neese@adaptx1.UUCP writes:
>
>>The equipment:
>>	Northern Star 386SX (16MHz, Award BIOS)
>>	Rodime RO3000TS drive (210M)
>>	Adaptec 1542B SCSI adapter
>>	Trident TVGA 8800 graphics adapter
>>	MSC Omnimouse, EasyData 2400bps modem
>>
>>The average seek time on my previous adapter (an ordinary DTC) was
>>about 12ms which increased to 21ms when I installed the Adaptec 1542B
>>adapter. The amazing 75% (!) increase cannot be normal or acceptable.
>>The transfer rate is OK, about 980K/s according to SPINTEST.
>>
>>BTW, I seem to have now a drive with 64 heads, 32 sectors/track and
>>199 cylinders (208666624 bytes). Has the conversion of the number of
>>heads and cylinders anything to do with the problem and is there a way
>>to configure the conversion scheme?
>>
>>I have tried to alter various parameters with the SCSICNTL but they
>>seem to affect neither the conversion nor the seek time.
>>
>>Any ideas?
>
>Sure, what most folks forget about is there is no physical interface to a
>SCSI drive.  That is to say, SCSI devices talk in logical blocks and not in
>terms of cylinder/head/sector.  This causes the adapter manufacturer to
>implement a translation scheme.  All SCSI adapters have to do this.  Ours is
>64 heads and 32 sectors per track regardless of the drive.  The number of
>cylinders is then calculated from the Read Capacity Command, which returns
>the total number of user blocks on the disk.
>Of course, this has the effect of goofing up the typical program that attempts
>to calculate average seek times and especially track to track seek times.
>Basically, there is no way a program can measure the seek times by using the
>head/sector information for a SCSI device as provided by the BIOS.  The only
>way this could be done would be for the adapter BIOS to get the information
>from the device paramter page of the mode data and use the number of heads
>and sectors from that.

    There is another way, and that is to issue a:

        READ CAPACITY Logical Block Address = X, PMI = 1

    Such a command would return the highest logical block address on the
    cylinder where X is located.   Therefore:

        E0  = READ CAPACITY LBA = 0, PMI = 1
        E1  = READ CAPACITY LBA = E0 + 1, PMI = 1
        E2  = READ CAPACITY LBA = E1 + 1, PMI = 1
        ..........................................

    Insert SEEKs where appropriate, and you can calculate the average seek time.
    
    In general, the average seek time is a function of the drive, not the
    controller.  The latter may introduce some delay (<1ms), but that's about it.

    In you case, SPINTEST seems to rely on the disk geometry info supplied by
    a SCSI host adapter BIOS.  As a result, the seek time reported by the
    program is inversly proportional to the number of cylinders, as reported
    by the BIOS.  Adaptecs have fewer cylinders (200 << 1024), and the brain-damaged
    SPINTEST reports a higher seek time for them.

                            This would then get us back into the problem of 
>crossing the 1024 cylinder limit.  Not to mention, drives using ZBR (zone
>bit recording) lie about these numbers as well.  They have a variable number
>of sectors per track, so they may just average it out, or put some other
>number there.
>This has been, and will continue to be, a problem with SCSI and the average
>performance measuring program.
>
>			Roy Neese
>			Adaptec Senior SCSI Applications Engineer
>			UUCP @  neese@adaptex
>				uunet!cs.utexas.edu!utacfd!merch!adaptex!neese


Alex Goykhman               goykhman_a@apollo.hp.com  
OS Technology Lab, OSSD/C   mit-eddie!apollo!goykhman_a
Hewlett-Packard, Inc.       (508) 256-0176 x2610