X-Nupop-Charset: English
Newsgroups: bit.listserv.novell
Date:         Wed, 11 Nov 1992 14:53:32 CST
Reply-To:     aagaard@nwu.edu
Comments:     Warning -- original Sender: tag was aagaard@CASBAH.ACNS.NWU.EDU
From:         Jim Aagaard <aagaard@NWU.EDU>
Subject:      EMM386, Direct Memory Access, & performance

There have been several postings recently about problems with the
EMM386 memory manager.  I'd like to add a slightly different
slant, and solicit any ideas or explanations anyone might have.

We have been installing a number of IBM PS/2s model 35SX (8535-
045) with Intel TokenExpress ISA 16/4 LAN adapters.  We have had
a number of problems which seem to be associated with the
simultaneous use of the EMM386 memory manager and the Direct
Memory Access capability of the Intel card.

Our first problem was with the system hanging while loading the
ODI driver.  Intel Technical Support suggested adding d=96 to the
load command for EMM386, which cured that particular problem.

However, we still had other problems.  On one particular machine
of the ones we've tried so far, the process proceeded to the
point of attaching to the server, but as soon as something was
typed on the keyboard the system displayed an error code in a
format similar to the codes which might be displayed during the
power-on self test.  This did not occur on an apparently
identical machine a few feet away on the same network, and did
not occur when DMA was turned off.

The most disturbing problem, however, has been a conflict with
diskette I/O.  On some diskette read and write operations, a
machine would hang with the diskette light on.  It could be reset
only by turning off the power.  This seemed to happen mostly with
moderately large files or after a succession of diskette I/O
operations.

We did some additional experimenting.  Loading both LSL and
IPXODI in regular memory seemed to help.  A different machine
running QEMM386 instead of EMM386 seemed to operate properly with
DMA on and all LAN modules loaded high.  Using the more recent
versions of HIMEM and EMM386 from the Windows 3.1 distribution
instead of the DOS 5.0 versions also reduced the severity of the
problem, and provided an additional 28K of upper memory blocks.

Intel, of course, is pointing at the Microsoft memory managers,
and at this point I have to agree.  We tried a Cabletron card,
which also uses DMA (but has no option to turn it off) and had
the same problems.  We don't relish trying to tackle Microsoft on
this problem, nor do we wish to invest in QEMM for each machine.

There have been some comments on the list recently about telling
EMM386 to avoid certain areas of memory.  We have not been able
to determine that the Intel or Cabletron cards use any areas of
high memory, so we have not eliminated any.

However, the cap to all of this was when we finally decided that
we had no choice but to use the Intel cards with DMA turned off,
but we wanted to determine what the performance penalty might be.
We downloaded the PERFORM3 program, which yielded surprising (at
least to us) results.  For example, using a record size of 1024
bytes, PERFORM3 reported a data rate of about 185 KBps with DMA
on and 217 KBps with it off!  (This is with a 4 Mbps token-ring.)
Does anyone know know how much of the hardware/software stack
PERFORM3 is testing?  Is any of this a quirk of the PS/2 or 386SX
architecture?

Any ideas?
                               Jim Aagaard
                               Northwestern University Library
                               aagaard@nwu.edu