Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!uunet!loft386!dpi
From: dpi@loft386.UUCP (Doug Ingraham)
Newsgroups: comp.os.minix
Subject: Re: minix on the macintosh
Summary: On an AT DMA is not as fast.
Message-ID: <512@loft386.UUCP>
Date: 15 Sep 89 01:41:33 GMT
References: <359@crash.cts.com>
Organization: Lofty Pursuits, Rapid City, SD USA
Lines: 57

In article <359@crash.cts.com>, jca@pnet01.cts.com (John C. Archambeau) writes:
> The issue of DMA is more of a performance issue.  We all prefer a 5 speed
> manual transmissionto a 4 speed (at least I do).  The idea behind DMA is to
> free the CPU from performing menial I/O tasks that do NOT have to be done by
> the CPU.

Because of a botched design it would be terrible to use the motherboard based
DMA on the AT.  Here are the reasons.

1)  Transfer rate is poor.  According to the AT Technical Reference Manual
    Page 1-7 (this is the original 6mhz manual) under system performance.
    The DMA controller operates at 3 MHz, which results in a clock cycle
    time of 333 nanoseconds.  All DMA data-transfer bus cycles are five 
    clock cycles or 1.66 microseconds.  Cycles spent in the transfer of bus
    control are not included.  If we assume a 512 byte or 256 word transfer
    the fastest it can go is 425 microseconds.  The CPU will be running at
    about half speed during this time because of the DMA.

2)  Transfer for 16 bit operations must go to word boundaries.  See the
    description under 3 why this is bad.

3)  Transfer must not cross over a 64k memory boundary for 8 bit transfers
    or 128k boundaries for 16 bit transfers.  Because of limitation 2 and
    3 the DMA almost always takes place to a buffer on an even byte boundary
    and guaranteed not to cross a 64k boundary.  This requires the CPU to
    perform a block move of the data after the DMA operation is complete
    to put the data in the proper place.  A 256 word move takes an additional
    172 microseconds at 6 mhz.

4)  The controller already has a whole sector of data in its internal
    buffer when it interrupts the processor.  The data should be transfered
    at the maximum rate the bus can handle so that the next operation
    can be queued.

5)  The DMA lines are not even connected to the Hard disk part of the
    controller card.  This makes DMA real tough to use. :-)

The total time for a DMA would be more than 597 microseconds.  Quite a lot
more when you consider that the CPU must honor an interrupt on completion
of the DMA in addition to the interrupt generated by the Disk controller
when it has the requested sector.  If the processor handles the request
directly the times are 258 microseconds for read and 215 microseconds for
output which is slightly faster.  When all things are considered it is
better than twice as fast to use the Special REP INPSW and REP OUTSW
instructions that the 286 offers.

> Just the thought of a Unix based OS on a machine without DMA is a taboo in my
> opinion.  Not having virtual memory is bad enough.  :)

If we are talking about a good implementation of DMA I agree.  Unfortunatly
on the AT DMA should be used only for the floppy.


-- 
Doug Ingraham (SysAdmin)
Lofty Pursuits (Public Access for Rapid City SD USA)
uunet!loft386!dpi