Path: utzoo!utgpu!attcan!uunet!super!udel!princeton!njin!rutgers!att!whuts!homxb!antique!cjp
From: cjp@antique.UUCP (Charles Poirier)
Newsgroups: comp.sys.amiga.tech
Subject: Re: A2090 SCSI vs Video contention - here we go again!
Summary: My mistake -- sorry!
Message-ID: <2466@antique.UUCP>
Date: 14 Dec 88 20:44:07 GMT
References: <2453@antique.UUCP> <5496@cbmvax.UUCP>
Reply-To: vax135!cjp (Charles Poirier)
Organization: AT&T Bell Labs, Holmdel, NJ
Lines: 39

In article <5496@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes:
>In article <2453@antique.UUCP> cjp@antique.UUCP (Charles Poirier) writes:
>>The old video-contention vs SCSI bugaboo is back, in FFS -- ...

Me again.  I apologize -- I stupidly fixed my devs:Mountlist but not
df0:devs/Mountlist.  Putting MaxTransfer = 512 *does* decrease video
contention problems.  I still want to do some fine tuning to find the
maximum transfer that works, but at worst it works as fast as OFS.

>I have a couple suggestions; first, are you running FastMemFirst
>before mounting your fast file system partitions ?

Yes.

>This is key; we want to keep the file system's buffers out of
>C00000 memory, which has the same access penalties as chip memory.
>
>Second, FastFileSystem transfers directly into a programs buffer.

Hard to say, but DPaint II (my test case) may well be using a CHIP buffer.

>In this case, you
>are better off setting your Mask value in your mountlist
>to exclude C00000 memory.  That way the FFS knows not to
>DMA directly into any data area there, but instead use its
>buffers, which, if you've run fastmemfirst before 
>mounting the ffs partition, will be in fast memory.

>    step 2: add a MASK=#007FFFFF
>	to the mountlist entries of your fastfilesystem partitions.

>		andy

I'll try it and see what happens.  Thanks very much!

-- 
	Charles Poirier   (decvax,ucbvax,mcnc,attmail)!vax135!cjp

   "Docking complete...       Docking complete...       Docking complete..."