Is WordSync good?
11 messages in this thread
I think you meant to say "that inherently plague improperly designed DMA
designs".
Larry, without dedicated DMA channels on the expansion buss the notion of a
"properly" designed DMA interface becomes a little specious.
Nonetheless, the fact remains that there are 'properly designed' DMA
interfaces, ie. DMA interfaces that, though they do share the DMA channels
with other devices/chips, they operate at the maximum speed available to
them in the times they have the bus. This is, of course, as opposed to
those devices that, due to design flaws, go into rety modes and operate
very slowly when the data overruns the DMA capability at the time. (I know
of only one such device; the 2090(A).
I think the specious arguments are coming from people like Ed Lippert,
formerly of the (former) C Ltd., who would go to virtually any lengths to
attempt to convince everyone that non-DMA controllers were faster than DMA
controllers, and would completely ignore the facts. I sincerely hope that
there are no other companies around who are so unscrupulous as to point to
the 2090 as if it represented all DMA contreollers, and claim superior
speeds for their own non-DMA controllers. 'nuff said.
Larry, I'll certainly grant that not all DMA interfaces are created
equally. Some are clearly more polite than others. It is certainly
possible to design a DMA interface that handles average situations well.
However, when the expansion buss is being driven near its limits, a DMA
interface will methodically maintain its performance. Another way to look
at that situation is that it won't necessarily get out of the way other
hardware or software needs to be serviced. I've yet to see ANY DMA
interface can't be pushed to the point that it causes interrupts to be
lost. In fairness to designs like the A590/A2091 (which I think is an
outstanding design), I have to push pretty far. The point could be made
that this is an extreme situation. It's up to the user to decide if they
need to operate at that extreme.
I think the best way to look at DMA philosophy is go as fast as you can and
then get out of the way. When Supra designed WordSync, the philosophy was
go as fast as is polite given the current state of the machine.
On any system, a well designed, well behaved DMA interface will outrun any
non-DMA design over the long haul. There are times where a non-DMA design
can have a faster throughput (particularly in small block size transfers),
but disks typically move much larger blocks, and a DMA design really
shines.
The CBM A2090 was a poor design from the get go. Several other companies
(ours included) have created excellent DMA designs. I'll put our HardFrame
up against any other design out there. We may not be the fastest in _all_
possible scenarios, but we'll be at the top in most. So will most good DMA
designs. Non-DMA systems will be far down the list.
The low level software drivers also contribute mightily to the speed of any
design.
This message is _not_ meant to start a religious war over DMA/non-DMA (that
horse has been beaten to death already), but I would like to stop the flood
of disinformation that this subject stirs up.
Rick, I don't want to start a religious war any more than you. I don't
want to argue with you about speed either. I've tested your interface and
think you have a fine product. And yes, DMA will usually be faster than
non-DMA. However, I don't think that max speed must be the only
consideration when designing an interface for the Amiga, and I know that a
well designed non-DMA interface does not have to be "far down the list." I
assure you no disinformation was intended, but for that matter I don't
really see where any was presented.
Clark, Fight? Me? Awwwwww! 😎 No, I agree that non-DMA may be fairly
fast, but there are a few tricks to it. I also agree that DMA is not
necessarily a good thing for the Amoeba, primarily due to some bad design
practices at C=. But, DMA is generally faster and can also lend speed to
other tasks running, since the CPU can work on those tasks and have to
bother with something as mundane as a disk load 8-)!
Rick Stevens/MicroBotics
I learned something recently that affected my view of a common hard disk
demonstration that I'd seen at Amiga shows. It turns out that AmigaDOS does
long-word reads when you ask to start a program. In other words, Deluxe
Paint is loaded into memory before execution, four bytes at a time. How
does this affect the DMA versus non-DMA debate? It would seem to me that
buffering would negate the reads, to some extent…
John,
Not sure where yu got that information, but I can assure you that the
file system and driver have considerably larger read requests during
program loading than 4 bytes. I just fired up TDebug to see what sort of
read lengths we were getting, and in amongst the requests was one for
166400 bytes, and another for 3584 bytes.
-larry
More technically, I heard it explained that LoadSeg() is issuing Read()s of
longwords, or maybe two longwords at a time. If the filesystem isn't, uhm,
cough, cough, on the same machine, then separate longword Read requests are
made. Of course, buffering makes up for the difference when everything
happens on the same machine.
'cough cough' indeed. 🙂
-larry