Subject: Re: Xmac68k building with reachover tools
To: Michael G. Schabert <mikeride@mac.com>
From: Michael R.Zucca <mrz5149@acm.org>
List: port-mac68k
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
----------------------------------------------