[comp.periphs.scsi] <8141517@lehtori.cc.tut.fi>

neese@adaptx1.UUCP (04/16/91)

>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.  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

goykhman_a@apollo.HP.COM (Alex Goykhman) (04/23/91)

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