Path: utzoo!mnetor!motto!ecijmm!eci386!ecicrl!clewis
From: clewis@ecicrl.UUCP
Newsgroups: can.usrgroup
Subject: Re: Is it the interleave?
Message-ID: <705@ecicrl.UUCP>
Date: 14 Oct 89 07:56:09 GMT
References: <891006074552.5152@tmsoft.uucp> <695@ecicrl.UUCP> <1989Oct8.192745.20807@tmsoft.uucp> <1989Oct10.221219.3571@eci386.uucp> <1989Oct12.202334.23282@eci386.uucp> <703@ecicrl.UUCP>
Reply-To: clewis@ecicrl.UUCP (Chris Lewis)
Distribution: ont
Organization: Elegant Communications Inc., Ferret Division, Toronto, Canada
Lines: 39

couple things, some related to this thread, some earlier...

In article <1989Oct12.202334.23282@eci386.uucp> jmm@eci386.UUCP (John Macdonald) writes:
>In article <1989Oct10.221219.3571@eci386.uucp> clewis@eci386.UUCP (Chris Lewis) writes:

>|As a canonical *best* case, just imagine a dd of a blocked disk, *one*
>|rotation per track read.  Which is on the order of 6 times faster than
>|systems that don't have or can't fully utilize 1:1 interleave.
>
>Note that even with Unix's internal read-ahead you still can't usually
>use 1:1 interleave (often far less) 

This point should be re-emphasized: 1:1 interleave generally
does not gain you *anything*, because the kernel/drivers are not
likely to be able to reissue an I/O before you're *past* the
next sector.  Unless:

	a) Your drivers are really smart and coalesce read-aheads
	   into multiple sector I/O's.  Of which track buffering
	   is a sort of a special case.  I did something similar with the
	   the DPT when I had the thing work on 1K physical sectors
	   and 512 byte logical ones.  (1K sector support in Xenix
	   is a little wierd, and similar to SRV2 if I understand
	   things correctly....)
	b) your application is wierd and reads sequentially with
	   big buffers.

Some of my benchmarks seemed to indicate that UNIX disk activity
can be fairly effectively modeled as random reads of 4-8 blocks, and that
with standard read-ahead you need a fairly substantial effective
interleave (phyical + mkfs) to avoid missing too many rotations.

Thanks, Brian for the explanation of how the Perstor works.
So much for guessing.
-- 
Chris Lewis, Elegant Communications Inc.
UUCP: {uunet!mnetor, utcsri!utzoo, uunet!attcan!lsuc, yunexus}!ecicrl!clewis
Moderator of the Ferret Mailing List (ferret-request@eci386)
Phone: (416)-294-9253