Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rice!uw-beaver!ubc-cs!alberta!herald.usask.ca!weyr!f70.n140.z1.FIDONET.ORG!David.Plummer
From: David.Plummer@f70.n140.z1.FIDONET.ORG (David Plummer)
Newsgroups: comp.sys.amiga.misc
Subject: Re: Copy does a Forbid?
Message-ID: <143.27F42C81@weyr.FIDONET.ORG>
Date: 28 Mar 91 17:28:50 GMT
Sender: ufgate@weyr.FIDONET.ORG (newsout1.26)
Organization: FidoNet node 1:140/70 - Double Check, Regina Sask
Lines: 40


 RG> In article <123.27E5AA36@weyr.FIDONET.ORG> 
 RG> David.Plummer@f70.n140.z1.FIDONET.ORG (David Plummer) writes: 
 RG> >Anyway, on to the question.  I'm using the ARP Copy command to back 
 RG> up  
 RG> >and restore my hard drive to a spare hard drive, and in order to 
 RG> speed  
 RG> >things up, I set the BUF parameter to 2000 (approx 1M).  Now it 
 RG> seems to  
 RG> >read/write a lot less, but I notice the screen blanker I'm using 
 RG> stops  
 RG> >dead in between drive activity, as does the mouse pointer if you're  
 RG> >using it. 
 RG>  
 RG> You probably have a non-DMA Hard Drive controller.  It's the process 
 RG> that 
 RG> controls the interface that steals all CPU cycles to do its bit 
 RG> pushing. 
 RG> For example, my TrumpCard (regular) uses a priority 10 controlling 
 RG> process. 
 RG> Every other process freezes on the system when continuous R/W to the 
 RG> HD 
 RG> is performed.  Yuk!  Just like a Mac ;) 
 RG>  
 
You really have to hate the way quoting wraps text like that....

Actually, I have a A590 (2091) which is (better be!) a DMA controller.  
You may be right to one extent though, since the IORequest Handler gets 
a priority of 11.  The scsi.device gets a priority of 12.  But the input 
device gets a priority of 20, so it still shouldn't lock the system up 
for that second or two.  I still don't know...



--  
David Plummer - via FidoNet node 1:140/22
UUCP: ...!herald!weyr!70!David.Plummer
Domain: David.Plummer@f70.n140.z1.FIDONET.ORG
Standard Disclaimers Apply...