Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!purdue!bu-cs!encore!xylogics!gws
From: gws@Xylogics.COM (Geoff Steckel)
Newsgroups: comp.arch
Subject: Re: DMA on RISC-based systems
Keywords: latency
Message-ID: <3003@xenna.Xylogics.COM>
Date: 12 Jun 89 16:23:43 GMT
References: <46500067@uxe.cso.uiuc.edu> <1989May26.170247.1165@utzoo.uucp> <1552@softway.oz> <182@dg.dg.com> <1620@softway.oz>
Reply-To: gws@Xylogics.COM (Geoff Steckel)
Organization: Xylogics, Inc., Burlington MA
Lines: 19

One concern that doesn't seem to be addressed on the DMAC vs. CPU data movement
question is transfer latency: the maximum delay between individual data items
moved.

Restrictions on latency (due to small buffers somewhere or a small decision
time) can override the otherwise attractive choice of using the CPU for
data movement.  If the CPU is not interruptable (or restricts interrupts)
during the data transfer other services (communications, screen, mouse, etc.)
may experience an unacceptable latency as well.

Sufficient buffering or other hardware to `smooth over' large latency times
can become more expensive (choose your metric) than putting in real or
simulated multiport memory and a dedicated DMAC; it entirely depends on the
desired performance.

For example, if the CPU must move data between every disk transfer, you may
miss revolutions on the disk... or maybe not.  Read, read, measure, and read
again.
	geoff steckel (steckel@alliant.COM, gws@xylogics.COM)