Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!houxm!houxz!vax135!cornell!uw-beaver!tektronix!hplabs!sri-unix!speck@CIT-VAX.ARPA From: speck@CIT-VAX.ARPA Newsgroups: net.unix-wizards Subject: none Message-ID: <12601@sri-arpa.UUCP> Date: Fri, 17-Aug-84 16:52:07 EDT Article-I.D.: sri-arpa.12601 Posted: Fri Aug 17 16:52:07 1984 Date-Received: Wed, 22-Aug-84 01:03:19 EDT Lines: 40 From: Don SpeckResponding 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