cjp@antique.UUCP (Charles Poirier) (12/09/88)
The old video-contention vs SCSI bugaboo is back, in FFS -- could someone knowledgeable about Amiga file systems please take a moment to peruse this problem? I installed FFS on my Quantum Q280 80meg SCSI HD, with a small first partition as Old File System. My controller is the A2090, I have 2 Meg expansion RAM, my startup runs the released 1.3 versions of SetPatch, FastMemFirst, BindDrivers, and Mount. My hddisk.device is the most recent I've heard of (V34.4 I think??). I tried adding MaxTransfer = 512 to the Mountlist entry for the FFS partition but this didn't help. FFS works great (2-4 times speedup) for low-bandwidth screens. But high-res 4-plane screens slow down FFS on my system by a factor of 10! (vs OFS.) Even if this behavior is specific to certain HD/controller combinations, it seems that the file systems are partly to blame, as indicated by the test described below. This is the same problem I had before with OFS, using an older version of hddisk.device. Now the problem has turned up again in FFS. Test: I copy the same iff picture to FFS and OFS. I open Dpaint II, high-res Lace. I load the picture from FFS - takes 40 seconds. I load the picture from OFS - takes 4 seconds, even with the DPaint II screen in front. Personal opinion -- OFS is doing something right that FFS is not. A read speed of 1 or 2Kbyte / sec is obviously unacceptable. I could drag the screen down to speed things up but this is messy, and for some programs (those with a full-screen window), impossible. I could flip to a lightweight screen, but this is not only messy but deadly, considering the bug in the screen-flipping code that crashes Amy if two Lace + one Nolace are in use. I hope you don't think I'm being too nitpicky - this really is a problem. Can someone suggest a solution, short of flinging the A2090 off a tall building? What would explain FFS being less forgiving of video DMA contention than OFS? I do hope someone can fix this. Maybe yet another version of hddisk.device?? A patch to l:FastFileSystem?? FFS is very nice otherwise, but I can't see living with crippled high-res permanently. Thank you very much, whoever you are. -- Charles Poirier (decvax,ucbvax,mcnc,attmail)!vax135!cjp "Docking complete... Docking complete... Docking complete..."
lphillips@lpami.van-bc.UUCP (Larry Phillips) (12/11/88)
> The old video-contention vs SCSI bugaboo is back, in FFS -- could > someone knowledgeable about Amiga file systems please take a moment to > peruse this problem? I wonder... I have seen this mentioned by a lot of people, and have been asking around about it. I have spoken with people who have the problem, and those that don't. There doesn't seem to be any consistent configuration that causes problems, nor one that works well. I can load a 640*400*4 picture into DPaint2 in 4 seconds from a hard drive running FFS, with none of the 'retry' sounds from the drive reported by those that have problems. This is true for both the 2090 I had, and the 2090A I have now, on a number of different drives, both SCSI and ST506. I don't run FAstmemFirst (I removed the 512K from $C00000, as it was too slow on my German designed A2000). I too run 1.3 SetPatch, and my hddisk.device is 34.4 (5 May 1988). My FastFileSystem is V34.85(8/10/88). Others I have spoken with have had the US designed 2000, and have had no problem, so it isn't that. I don't have any idea what it is, but perhaps with enough input, we can figure it out, perhaps even before you throw your 2090 off a tall building. -larry -- "Intelligent CPU? I thought you said Intel CPU!" -Anonymous IBM designer- +----------------------------------------------------------------+ | // Larry Phillips | | \X/ lpami.wimsey.bc.ca!lphillips or van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------+
andy@cbmvax.UUCP (Andy Finkel) (12/14/88)
In article <2453@antique.UUCP> cjp@antique.UUCP (Charles Poirier) writes: >The old video-contention vs SCSI bugaboo is back, in FFS -- could >someone knowledgeable about Amiga file systems please take a moment to >peruse this problem? > >= 512 to the Mountlist entry for the FFS partition but this didn't help. MaxTransfer will limit the amount transfered by the FastFileSystem... this is not the answer to your problem. I have a couple suggestions; first, are you running FastMemFirst before mounting your fast file system partitions ? 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. Normally this works great...less copying around, data ends up exactly where it is supposed to be, etc. However, what if the program has its data area in C00000 memory and you are in a high DMA bandwidth using situation ? That's right, slowdown. In this case, you are better of 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. So, step 1: make sure FastMemFirst is before the ffs mounts in your startup-sequence file step 2: add a MASK=#007FFFFF to the mountlist entries of your fastfilesystem partitions. andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "Possibly this is a new usage of the word 'compatible' with which I was previously unfamiliar" Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
cjp@antique.UUCP (Charles Poirier) (12/15/88)
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..."
papa@pollux.usc.edu (Marco Papa) (12/19/88)
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 -- could ||someone knowledgeable about Amiga file systems please take a moment to ||peruse this problem? |I have a couple suggestions; first, are you running FastMemFirst ^^^^^^^^^^^^ |before mounting your fast file system partitions ? My question is as follows: what if you've one of the "autoboot" devices like the GVP board or the A2090A? With the GVP one can have a single partition, ALL of it FFS and still boot from it. So the FFS is up even before FastMemFirst can ever be run. |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. |Normally this works great...less copying around, data ends up exactly |where it is supposed to be, etc. However, what if the program |has its data area in C00000 memory and you are in a high DMA bandwidth |using situation ? That's right, slowdown. In this case, you |are better of 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 1: make sure FastMemFirst is before the ffs mounts in your | startup-sequence file Can't do this when "autobooting" an FFS partition. [or is there another way to di it?] | | step 2: add a MASK=#007FFFFF | | to the mountlist entries of your fastfilesystem partitions. I guess in my case, I can only do Step 2. Is that enough to avoid all the problems? -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
andy@cbmvax.UUCP (Andy Finkel) (12/20/88)
In article <14146@oberon.USC.EDU> papa@pollux.usc.edu (Marco Papa) writes: >|I have a couple suggestions; first, are you running FastMemFirst >|before mounting your fast file system partitions ? > >My question is as follows: what if you've one of the "autoboot" devices >like the GVP board or the A2090A? With the GVP one can have a single >partition, ALL of it FFS and still boot from it. So the FFS is up >even before FastMemFirst can ever be run. There are 2 possible solutions to this: 1) Set your GVP hard disk to automatically add a minimum number of buffers when it fire up; 5 would be about right. Then add the rest of the buffers via your startup-sequence (Addbuffers). 2) or you could use 2 partitions anyway :-) >| step 2: add a MASK=#007FFFFF >| >| to the mountlist entries of your fastfilesystem partitions. > >I guess in my case, I can only do Step 2. Is that enough to avoid all the >problems? Nope; you want to keep the filesystem buffers out of C00000 ram as well. (and you can do it via step 1) >-- Marco Papa 'Doc' -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "Possibly this is a new usage of the word 'compatible' with which I was previously unfamiliar" Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
papa@pollux.usc.edu (Marco Papa) (12/20/88)
In article <5524@cbmvax.UUCP| andy@cbmvax.UUCP (Andy Finkel) writes: |In article <14146@oberon.USC.EDU| papa@pollux.usc.edu (Marco Papa) writes: ||My question is as follows: what if you've one of the "autoboot" devices ||like the GVP board or the A2090A? With the GVP one can have a single ||partition, ALL of it FFS and still boot from it. So the FFS is up ||even before FastMemFirst can ever be run. | |There are 2 possible solutions to this: | |1) Set your GVP hard disk to automatically add a minimum number |of buffers when it fire up; 5 would be about right. Then |add the rest of the buffers via your startup-sequence (Addbuffers). I guess I should do AddBuffers FFS: AFTER FastMemFirst, right? -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
elg@killer.DALLAS.TX.US (Eric Green) (12/20/88)
in article <14146@oberon.USC.EDU>, papa@pollux.usc.edu (Marco Papa) says: > In article <5496@cbmvax.UUCP| andy@cbmvax.UUCP (Andy Finkel) writes: > |I have a couple suggestions; first, are you running FastMemFirst > |before mounting your fast file system partitions ? > My question is as follows: what if you've one of the "autoboot" devices > like the GVP board or the A2090A? With the GVP one can have a single > partition, ALL of it FFS and still boot from it. So the FFS is up > even before FastMemFirst can ever be run. Note that the GVP is NOT a DMA hard disk controller, so it doesn't much matter. Video contention is only a problem with DMA to chip or "half-fast". > | step 2: add a MASK=#007FFFFF > | to the mountlist entries of your fastfilesystem partitions. > > I guess in my case, I can only do Step 2. Is that enough to avoid all the > problems? Step 2 is useless without step 1, because the FFS has allocated its buffers in the "half-fast" RAM (since it's first on the free memory list for "fast" RAM). Thus, when you make accesses into "fast", data goes to "fast", when you make accesses into "slow", data goes into "slow" -- with or without the MASK. Don't even bother -- all it does is add an additional block move, when using a non-DMA controller and no "fastmemfirst". BUT, you might want to ask GVP about their autoboot code... it MAY do an equivalent to "fastmemfirst". In which case your MASK WOULD be useful, if only to avoid having the CPU thrash around in "chip" when it could be thrashing around in "fast". -- Eric Lee Green ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg Snail Mail P.O. Box 92191 Lafayette, LA 70509 Netter A: In Hell they run VMS. Netter B: No. In Hell, they run MS-DOS. And you only get 256k.