24bit/32bit DMA WARPS 16MB limit??
Craig Sampson
sorts of OS/2 memory topics. The one that really scared me though was
the inability of ISA motherboards using 24 bit DMA controllers to
effectively use >16MB of memory.
Now what does this actually mean? People are out there using 32MB and
more all the time. Is the extra 16M+ just swap/virtual disk space? I
find it difficult to believe that these ISA boards are sold as
'expandable to 64MB' and sometimes more whilst not being able to use this
memory for much more than a glorified smartdrive cache.
The particularly frightening thing is that I've just got WARP and I have
fallen in love, not right away mind, but I have a view at to its
potential; not realised in my 486DX33 8MB, the first thing to do I figure
is buy a 540M HD and then pop in 16M RAM to bring things up to 20MB (have
to dump 4 of my 1MB SIMMS).
Before I whizz out and spend $700 of my hard earned bucks on memory though
I want to be damn sure I'm going to get some 'real' use out of it,
otherwise I'll just get an enhanced IDE controller (or maybe go SCSI-2)
and blast on a high speed HD. Maybe I should talk directly to IBM about
this? Seems to me there are a lot of knowlegable people here though, so
whats the real deal?
Worried, dazed and confused...
Craig.
jar...@cid.aes.doe.ca
The 16 MB limitation on ISA motherboards only applies to busmastering
DMA controllers, eg. Adaptec AHA1542x. The problem is that the address bus on
the motherboard is only 24 lines hence 16 MB, and the DMA controller on the
busmaster device can only address these 24 lines. This does not apply to PIO
devices, eg. IDE controllers, Adaptec AHA1522x controllers, etc. These type of
devices can access all memory that is on the motherboard.
================================================================================
A. James Arnold (ARQI) Tel: 1-416-739-4855
Atmospheric Environment Service FAX: 1-416-739-4288
4905 Dufferin Street Email: jar...@cid.aes.doe.ca
Downsview, Ontario M3H 5T4
Canada
================================================================================
Villy Madsen
>An OS does not have to do this. Take for instance, Linux. Linux ensures
>that the buffers that are allocated to the controller are allocated below
>16MB limit so there can be no memory addressing conflicts between the system
>and the controller (imagine a controller given a >16MB address. The ISA bus
>truncates the address to one below 16MB so your buffers end up somewhere else
>unexpectedly...oops)
>
The problem is not really (from a system design point of view) with normal disk
IO. You can allocate the Disk buffers in low core, and as you say some operating
systems do that. The problem becomes extreme when you are talking about
virtual memory systems. If a page has to be swapped in or out, you did have to move
it into memory somewhere below the 16MB limit, and then do a memory to memory transfer
to move it to where you want it. This can get really nasty to implement in a
multi tasking operating system. (as well as being wasteful of resources)
It could be implemented using a NONDMA (i.e. programmed IO) disk device driver. I notice
that the adaptec drivers will only work in Programmed IO mode on an ISA system. (at least
the one that I've got)
by low core I mean <16MB
Villy G. Madsen ISP,
Systems Consultant, Systems Integration
Canadian Utilities Ltd, Edmonton, Alberta Canada T5J 2V6
voice 403-420-5093
fax 403-420-3737
The TEAMIBM Network
that the problem 1) only exists on ISA buses, and 2) only exists when
BusMastering adapter cards are used in an ISA slot. This is *NOT* a
problem with cards that use DMA channels that are not BusMasters.
Therefore, your questions-
1. IBM1S506.ADD is a device driver, not an ISA adapter card, therefore,
it does not impose a problem with >16MB RAM. ( FWIW, the adapters
supported by this driver are PIO devices ).
2. DMA transfers require fewer processor cycles to transfer data, so
they are much more efficient in a multi-tasking environment.
3. SBCD2.ADD is similar to IBM1S506.ADD with the exception that it is
Interrupt driven ( IRQ ) rather than PIO.
In most cases, the problems are caused by SCSI adapters. There aren't
many ISA BusMastering cards out there besides the SCSI ones.
Hope this helps clear up the confusion.
Norm Creech <OS/2 - AIX/RISC/6000 - Linux bigot>
Team OS/2 No...@nando.net
rth...@rocknrob.eng.hou.compaq.com
: many ISA BusMastering cards out there besides the SCSI ones.
There are BusMastering Network cards too.
RokNroB
Keith Medcalf
>To answer your questions relative to DMA and >16MB RAM lets first clarify
>that the problem 1) only exists on ISA buses, and 2) only exists when
>BusMastering adapter cards are used in an ISA slot. This is *NOT* a
>problem with cards that use DMA channels that are not BusMasters.
>Therefore, your questions-
>1. IBM1S506.ADD is a device driver, not an ISA adapter card, therefore,
>In most cases, the problems are caused by SCSI adapters. There aren't
>many ISA BusMastering cards out there besides the SCSI ones.
>Norm Creech <OS/2 - AIX/RISC/6000 - Linux bigot>
> Team OS/2 No...@nando.net
This is the most famous YO-YO bug in OS/2. Fixed and broken and fixed and
broken and fixed and broken and fixed and broken. With the next CSD it will
probably be fixed again since it is presently broken again :)
---
Keith Medcalf kmed...@io.org #include <YourRisk.HPP>
275 Broadview Av #152 #include <Mileage.HPP>
Toronto ON Canada +1-416-465-9578 #include <NoWarranty.HPP>
David Burton
> To answer your questions relative to DMA and >16MB RAM lets first clarify
> that the problem 1) only exists on ISA buses, and 2) only exists when
> BusMastering adapter cards are used in an ISA slot. This is *NOT* a
> problem with cards that use DMA channels that are not BusMasters.
Right. There are two kinds of DMA on ISA machines: the kind that
uses the motherboard's DMA channels, and the more sophisticated kind
that uses bus-mastering by the adapter.
But a card that uses the AT's sorry DMA channels is assuredly much
slower than a decently-designed bus-mastering DMA or programmed-I/O
adapter. I don't think any modern disk or SCSI adapter uses the AT
motherboard's DMA channels (please, someone correct me if you know
of an exception). There's simply no point in designing an adapter
that uses the motherboard DMA channels, since such an adapter would
be slower, more complex (and expensive), harder to write device
drivers for, and probably less reliable than it could have been if
designed to use programmed I/O, instead.
So, when people refer to DMA adapters (e.g., Adaptec SCSI adapters),
they're usually talking about the bus-mastering variety, which are
vastly more efficient than adapters that use the motherboard's DMA
channels.
> 2. DMA transfers require fewer processor cycles to transfer data, so
> they are much more efficient in a multi-tasking environment.
. . .
Sorry, this is widely-believed, and often-repeated (especially by
manufacturers of bus-mastering adapters!), but it is not true.
A well-designed non-bus-mastering (programmed-I/O) card is about
as efficient as a bus-mastering DMA card, and can easily be *more*
efficient in some circumstances!
(Note: I'm not talking about the very cheap little 8-bit cards
that have little or no buffer on the adapter. Those are VERY slow.)
There are many variables that affect the relative performance of
bus-mastering vs. programmed-I/O adapters, and can make one faster
than the other in a particular comparison. However, the question of
whether or not your system is doing multi-tasking is NOT one of
those variables. That is of no importance when asking the question
of which kind of adapter is fastest, since neither variety of
adapter requires that the CPU burn cycles while awaiting completion
of a physical I/O operation by the device. With programmed-I/O, the
card simply buffers the data, and interrupts the processor when it
is time to use a block-I/O (e.g. "REP INSW") or block memory-move
(e.g. "REP MOVSW") to move data to or from main memory.
Of course, if you are not using multi-tasking, then it doesn't
matter very much how fast the adapter is, as long as it is faster
than the devices that are attached to it. But that is unrelated to
the question of which adapter is fastest. Whether you are using
multi-tasking determines only whether you *care* about speed; it
does not significantly affect the relative performance of DMA vs.
programmed-I/O adapters.
The processor cycles used by the programmed-I/O card to move the
data are those required by the block-I/O instruction. This is apt
to be very similar to the amount of overhead used by the DMA card to
do the equivalent transfer. The actual CPU cost might be a bit
more, or a bit less. The DMA card uses its processor cycles when
CPU operation is suspended (starting with the first cache miss) to
await access to RAM, due to a DMA transfer being in progress.
Now, the block-I/O requires two operations to transfer a word of
data (one cycle for the I/O access, and one for the RAM access), but
the DMA card can do both simultaneously. I.e., with programmed-I/O,
the data moves from RAM-to-CPU-to-adapter (or from adapter-to-CPU-to
RAM), but with DMA the transfer is directly from RAM-to-adapter (or
from adapter-to-RAM). The CPU "middleman" is left out of a DMA
transfer.
So, you might expect that the DMA design could be faster than the
programmed-I/O design. However, this is apt to be only a small
advantage, in practice, due to the caching of RAM in modern
processors, which can make the RAM/ CPU transfers actually happen in
very high speed 16-byte cache-line bursts. With an ISA controller,
the cost of the RAM access is almost zero compared to the cost of
the I/O access to the card across the very slow AT bus (which is a
cost incurred by both DMA and programmed-I/O cards). There are
performance costs to DMA which can easily swamp this modest savings.
One such cost is the DMA setup time. The DMA driver and card must
be able to mimic the logical/physical memory mapping that the CPU
does. This requires that the driver convert logical addresses to
physical addresses, and program the DMA adapter to do its I/O
transfers to/from the proper physical addresses in RAM (which can
mean that consecutive words must sometimes be transferred to very
different RAM addresses). Essentially, the bus-mastering card must
duplicate the paged memory management facility of the processor,
and the device driver must ensure that the card's address-mapping
is consistent with that of the CPU.
In contrast, with a programmed-I/O adapter, this overhead (and
complexity) simply does not exist.
The DMA design also incurs the additional overhead of negotiating
the transfer of bus control before and after each movement of data
between the adapter and main memory.
That is also a cost that programmed-I/O adapters do not incur.
The DMA card designer has to make a decision regarding the amount of
data which the card transfers in a burst, before yielding the bus to
the CPU. If the card transfers large amounts of data per burst, it
will minimize the cost of the transferring bus ownership before and
after each burst. However, that causes the CPU to be suspended for
longer periods of time, and thus forgoes any hope of running the CPU
(from cache) to a significant extent while the DMA transfer is
taking place. Plus, it increases worst-case system-wide interrupt
latency. On the other hand, if the card does its DMA transfers in
small bursts, then the cost of negotiating bus ownership before and
after each burst can be substantial.
With a programmed-I/O card, there is no effect on worst-case system
interrupt latency (since block-I/O instructions are interruptible),
and of course there is no cost for transferring bus ownership (since
bus ownership is never transferred).
In addition, when you have two or more bus masters, there are apt
to be timing differences between them. This can affect both
performance and (more importantly!) reliability. Just because your
RAM is rock-solid when the CPU accesses it is no guarantee that it
will also be reliable when some other bus master, with different
timing characteristics, is doing the access. So, where do you find
a good memory-testing program that tests the RAM while doing its
accesses to RAM via the other bus master, rather than the CPU? The
answer, of course, is that you don't. Such programs do not (to the
best of my knowledge) exist. So, the question becomes: "do you feel
lucky today? Well, do ya, punk??"
In practice, the really major performance difference is not between
bus-mastering cards and programmed-I/O cards. It is between 32-bit
local bus cards, which can move data to/from the adapter quickly,
and 16-bit ISA cards, which cannot.
(But if you are using a ISA card, you may be able to improve
performance noticeably by increasing the AT I/O bus clock speed from
its usual 8 MHz to a higher rate. Many BIOS Setup programs let you
adjust this, though how high you can push it depends on how fast
your slowest adapter is.)
-Dave Burton
primary: <dbu...@salzo.cary.nc.us> alternate: <salzo!dbu...@dg-rtp.dg.com>
For my PGP public key, finger dbu...@cybernetics.net or dbu...@ios.com