Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!haven!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: MSCP for you and me
Message-ID: <14162@mimsy.UUCP>
Date: 26 Oct 88 04:36:27 GMT
References: <10337@eddie.MIT.EDU>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 55

>>[Chris Torek:] The 4.3BSD UDA50 driver treats unknown disks as type
>>`ra81'.  I considered this bogus [...]

Actually, I think this was wrong.  I looked again at what was supposed
to be the 4.3BSD release (according to our RCS files, not the SCCS
files at Berkeley), and it should have complained about unknown drive
types.  (It did a switch on the number part of the encoded media ID.)
But again, all those third-party disks claim themselves to be RA81s anyway.

In article <10337@eddie.MIT.EDU> nessus@athena.mit.edu (Doug Alan) writes:
>I have another question for BSD disk driver wizards: I discovered
>sometime recently that if I use "tunefs" to change "maxcontig" for a
>filesystem from 1 to 2, the read performance of the filesystem (for a
>single process) increases about 25%. ...

(Obviously you are not using a UDA50---I never got any repeatable change
in any performance measurements I ran for any tunefs parameters.)

>The man page for "tunefs" says you should only increase "maxcontig" on
>a device driver that can chain several buffers together in a single
>transfer.  Can the MSCP device driver do this?

The driver does not do it itself, but the controller could quite easily.

>Is there any reason why I shouldn't leave "maxcontig" set to 2.

No!  You might tell everyone what controller and drive this is, though.
The only way to find the proper tunefs values is to experiment; it is
easier if someone else has already done the experimenting. . . .

>...  Another issue is that our disk controllers are
>smart, and you can set them to prefetch blocks (the controller also
>does caching -- prefetched blocks go into the cache).  Setting the
>prefetch to be 32 sectors (2 blocks) also resulted in another little
>increase in filesystem read performance for a single process.

Probably because in those cases where the read-ahead block was
contiguous but was not delivered to the controller soon enough, the
second read command had to wait for most of a revolution.  When it was
delivered soon enough, the controller did the chaining whether or not
you had prefetching set; now it gets the block cached whether the
read-ahead is requested immediately or after a slight delay.

You might find that raising the read-ahead and the maxcontig factors
together helps further.  But you (or someone else) will have to try
it to be sure.

(It would sure be nice if controllers came with *real* documentation
as to characteristics like `code delays to search on-board cache',
`will (not) read full tracks without waiting for index', etc.  Then
you *might* be able to predict some of this, after instrumenting the
drivers carefully.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris