Mac DMA

Mac DMA

Post by David J. Howar » Fri, 02 Feb 1990 21:50:00



DMA on the Mac, if done correctly, could actually be very advantageous.
The problem with having the CPU handle all the block memory transfers
is that it has to fetch instructions, read from memory/device, write
to memory/device and handle looping.

  move (An)+,(An)+  takes 9 clock cycles best case on the Mac II
                         12 clock cycles worst case
  DBcc Dn,<label>  takes 3 clock cycles best case, count not expired
                         11 clock cycles worst

  So the 68020 needs from 12-23 cycles per 32 bit word for block
  memory moves.  When it is driving the SCSI chip, it can move
  only a byte at a time, which means that it would take 4 one byte
  transfers to move 32 bits, or 48-92 cycles per 32 bit word when
  doing SCSI transfers.
  A good DMA controller, on the other hand, can pump data into
  memory at 4 clock cycles per 32 bit word (after setup) if designed
  correctly.  Even if the processor can not access RAM while the DMA
  controller is, the performance difference is still substantial.
  These times were acquired from the 68020 user's manual from
  Motorola and assume a 1 clock cycle wait state which the
  Mac II uses.
  One thing to keep in mind, though, is that even a factor of
  10 increase in performance at this low level will NOT result
  in a user perceivable speedup of 10.  It will be faster from
  the user's standpoint, but by how much is not easily quantified.

           Give me DMA or give me death :-) :-)
--
usenet: {decvax, cbosgd, sun}!mandrill!howarth    David J. Howarth


 
 
 

Mac DMA

Post by John Gilmo » Fri, 02 Feb 1990 23:27:00



Quote:> DMA on the Mac, if done correctly, could actually be very advantageous.
>   One thing to keep in mind, though, is that even a factor of
>   10 increase in performance at this low level will NOT result
>   in a user perceivable speedup of 10.  It will be faster from
>   the user's standpoint, but by how much is not easily quantified.

A friend has been doing some performance work on A/UX; it turns out
that the main problem is rotational latency and seek time -- as usual
with disks.  The contribution of software "DMA" seems to not be
significant.  Put a scope on the SCSI bus and watch where it spends its
time -- on a fast disk, maybe 18 ms waiting for the disk to turn and 2
ms moving data over the SCSI bus.  If you sped up the 2ms to .2ms,
you'd wait 18 ms instead of 20 -- a bit 10% (not 10x) speedup.

Since A/UX runs the ancient System V file system, it has to seek all
over to read a file, and as James Woods pointed out, this is the major
cause for the slow A/UX disk timings.

All I know is that even if they speed up the file system, 14-char
filenames are a major pain in the *after spending 5 years on Suns.
Let's hope the ATT/Sun merge fixes this once and for all.
--

                "Watch me change my world..." -- Liquid Theatre