none

speck at CIT-VAX.ARPA speck at CIT-VAX.ARPA
Sat Aug 18 06:52:07 AEST 1984


From:  Don Speck <speck at CIT-VAX.ARPA>

    Responding to Kirk McKusick's analysis of disk throughput:

>   Thus the interesting question is why your system drops revs with
>   only a 4K skip. I will suggest two possibilities. The first is that
>   the rdist and/or sdist parameters (in struct hpst, hp.c) are set
>   up incorrectly for your controller/disk combination.

    I experimented with the sdist/rdist parameters for our 9775 (using
adb -k -w /vmunix /dev/mem) while running 'cp bigfile /dev/null' and
'iostat 2'.  Any value of sdist from -1 to 31 made no difference; any
value of rdist less than 32 (the number of sectors per track) made no
difference.  When I raised rdist to 32, throughput rose from 40 4K-byte
blocks/second to about 100.

    In hpustart(), the calculations for when to do a search instead of
a transfer depend on the controller's "lookahead" register `hpla', which
on the SI 9900 is "not emulated - reads as 0".	(The calculation is also
wrong!).  For any value of rdist less than nsect (# sectors/track (32)),
the controller was told to "search" before every transfer.  (Search is
supposed to seek, and then wait for the desired sector).  In the 9900,
"Search" appears to be equivalent to "Seek" -- apparently the controller
just doesn't *know* the rotational position of any of our disks.

    The fix is to add the line:  hpsoftc[mi->mi_unit].sc_doseeks = 1;
to the appropriate place in hpmaptype().

    Our 9775 is mapped as two RM05's.  DEC diagnostics measure the seek
time as 1.14ms regardless of distance.	Apparently the 9900 doesn't
emulate "Seek" for drives mapped as several logical drives (overlapped
seeks on two logical drives make no sense when there's only one physical
disk arm).  Seek *does* take the right amount of time on our 9766.

    The 9900 also doesn't bother to emulate the hpec1 & hpec2 registers.
The code in hpecc() case ECC looks like it will screw up on an SI 9900.

    Does anyone know why the driver hangs when it reads a bad sector as
part of a large (8K) read on a raw device?
						Don Speck



More information about the Comp.unix.wizards mailing list