Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!uwvax!dogie.macc.wisc.edu!csd4.milw.wisc.edu!bbn!mit-eddie!uw-beaver!rice!sun-spots-request
From: lmb@vicom.com (Larry Blair)
Newsgroups: comp.sys.sun
Subject: Re: Optimization for caching controllers (Oops... I eat crow again)
Keywords: Hardware
Message-ID: <3744@kalliope.rice.edu>
Date: 8 Jun 89 03:43:09 GMT
Sender: usenet@rice.edu
Organization: Sun-Spots
Lines: 63
Approved: Sun-Spots@rice.edu
X-Sun-Spots-Digest: Volume 8, Issue 21, message 1 of 5

In Sun-spots v7n303, I wrote:

> Using a non-caching disk controller and BSD's traditional one sector at a
> time transfers, it is impossible to read successive physical blocks from a
> disk without having to wait for the disk to rotate completely around for
> each sector.  BSD automatically tries to compensate this by utilizing the
> sectors in a hopscotch arrangement that separates the sectors used to
> write a file by a distance that is hopefully wide enough so that when the
> file is read back, each successive read will be started before the next
> sector needed has passed the head.
> 
> ............
>
> Now for the voodoo.  Many people using the Interphase or Ciprico simply do
> a "tunefs -d 0", which eliminates all compensation for rotational delay.
> After thinking about that, I decided to do a little testing.  SunOS reads
> and writes are based on an 8K logical block size, when comes to 16
> sectors.  Of course, not all accesses are going to be for the full 8K, but
> none are going to be larger.  I suspected that inserting a rotational
> delay between each group of 16 sectors might be an improvement.

Art Hays <lsr-vax!art@uunet.UU.NET> wrote the following to me:

> I thought with a logical block size of 8192 (16 512 byte sectors)
> only one disk transaction would be required to read all 16 sectors.
> In other words, the controller does a 8192 byte DMA to read the logical
> block.  If this is correct, aren't you using 'sector' above sometimes when
> you really mean 'logical block'?
> 
> The man page for 'tunefs' says 'maxcontig' is the number of
> contiguous blocks laid out before forcing a rotational delay.  IF by
> 'blocks' they mean a LOGICAL block, then '-a 16' would put a rotational
> delay after a string of 16 LOGICAL blocks.  For 8k logical block size,
> this would be after 16*8k or 128KBytes.  Since this is the size of the
> FIFO in the 753/7053, this would seem appropriate.

The term "block" is used inconsistently throughout the Sun documentation.
If you look at icheck(8), you'll see (from running it) that block means
"sector".  Art is probably correct, however.  The Interphase 4200 also has a
128K cache, so the value I got by experimentation may be right for reasons
that I misattributed.  In fact, looking through the source for Interphase's
driver seems to indicate that the basic DMA transfer is 8K.

My experimental situation was reading and writing files of 2MB.  I chose
that size to minimize filesystem overhead, seeking to the inode, etc.,
while staying in the same cylinder group.  If I ever get a chance, I'll
repeat the experiment with smaller file sizes.  If the "blocks" in tunefs
are 8K in size, the advantages of caching should diminish when the files
are below 128K and disappear when they go below 8K.

I'm still not entirely sure why -a 16 worked faster than -d 0.  There
really shouldn't be any difference.  Since 128K is nearly 8 tracks, I
would expect the head to head switching time (which Interphase tells me
is significant) to overshadow any rotational delays inserted between 128K
reads.

Btw, the Ciprico has a 512K cache, so -a 256 would be the value to use
there.

Anyone have any comments?  Anyone have any source?

 
Larry Blair   ames!vsi1!lmb   lmb@vicom.com