Subject: Re: Xmac68k building with reachover tools
To: Michael G. Schabert <mikeride@mac.com>
From: Michael R.Zucca <mrz5149@acm.org>
List: tech-x11
Date: 01/07/2004 13:49:36
On Jan 6, 2004, at 9:04 AM, Michael G. Schabert wrote:

> While the 80/40 Mhz 840AV is the fastest stock Mac68k ever made, it 
> will have an exaggerated example of the "local disks slower than NFS 
> mounts" issue mentioned with the 630 above when used with NetBSD. This 
> is because there is no support yet for the DMA SCSI engine, so drive 
> access is quite slow. There was work being done on it, but I don't 
> believe it's in a useful form yet.

With the last patch I submitted to this list, the data gets moved with 
the DMA engine just fine. So I suppose it's "useful" in that regard.  
It's just that there's only a marginal increase in transfer speed. As 
far as I can tell, the problem stems from the fact that the transfers 
between the disk and the SCSI controller are still happening 
asynchronously, which is slow regardless of the fact that the DMA 
engine, not the CPU, is pushing the data around. The way to fix this is 
to enable synchronous transfers.

The problem with synchronous transfers right now is that 
sync-negotiation fails at boot up. This happens because the generic NCR 
driver insists on doing a short, odd-aligned and/or odd-sized transfer 
during sync negotiation. The DMA engine can't handle transfers like 
that, so the code falls back to PIO. Apparently, the NCR interprets PIO 
transactions during sync negotiation as a sync failure. I think this 
problem could be solved if the generic NCR driver were changed to use a 
passed-in buffer (which could be aligned) rather than some random 
memory. Either that or the generic NCR code should be modified so that 
the sync negotiation code can be overridden by the platform specific 
driver altogether and we could roll our own sync negotiation routine.

I believe that if the sync negotiation problem could be solved, the 
transfers would happen as fast as the hardware would allow between the 
disk and the SCSI controller. After that, there are some other tweaks 
that could be applied to improve DMA performance (i.e. reload the DMA 
registers on the DMA interrupt instead of the SCSI interrupt, use both 
DMA registers to hide interrupt latency, etc.) but I think these are 
small in comparison to enabling synchronous transfers.

In any case, I don't think I'm up for this time-wise at the moment. So 
if somebody is feeling their oats they can pick up my last patch and 
run with it.

-- 
----------------------------------------------
  Michael Zucca - mrz5149@acm.org
----------------------------------------------
  "I'm too old to use Emacs." -- Rod MacDonald
----------------------------------------------