howarth@mandrill.CWRU.Edu (David J. Howarth) (02/19/88)
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
csnet: howarth@mandrill.CWRU.edu
arpa: howarth@mandrill.CWRU.edu gnu@hoptoad.uucp (John Gilmore) (02/27/88)
howarth@mandrill.CWRU.Edu (David J. Howarth) wrote: > 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 butt after spending 5 years on Suns. Let's hope the ATT/Sun merge fixes this once and for all. -- {pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu gnu@toad.com "Watch me change my world..." -- Liquid Theatre