Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!spdcc!dyer
From: dyer@spdcc.COM (Steve Dyer)
Newsgroups: comp.unix.xenix
Subject: Re: 16-bit versus 32-bit memory performance
Message-ID: <435@spdcc.COM>
Date: Sun, 6-Dec-87 13:47:47 EST
Article-I.D.: spdcc.435
Posted: Sun Dec  6 13:47:47 1987
Date-Received: Fri, 11-Dec-87 06:22:25 EST
References: <388@ddsw1.UUCP> <620@omen.UUCP>
Organization: S.P. Dyer Computer Consulting, Cambridge MA
Lines: 71

In article <620@omen.UUCP>, caf@omen.UUCP (Chuck Forsberg WA7KGX) writes:
> SCO warns not to use 16 bit memory on 386 motherboards.  I have not
> seen any problems resulting from this, other than speed.  Code running
> from 16 bit memory behaves like a 4 mHz 286 box.  So I only use the
> extra memory when running VP/ix.

Let (re)offer my experience with 16-bit memory when using an Intel Inboard 386
in an 8mhz PC/AT.  The Inboard has 64K cache which offsets some of the
performance problems that Chuck reports with systems based on the Intel 386
motherboard.  It's still true that 16-bit memory is a lose, although not as
bad as Chuck reports--an Inboard system with only 16-bit memory is still better
at running 286 code than the equivalent 286-based 8mhz AT.  To be honest, I
haven't examined the XENIX 386 system with only 16-bit memory (my tests
reflected the chronology of my system upgrades, and I'm loathe to open it up
and rip out the 32-bit memory to try it now...)  So, there might yet be some
disproportionate disadvantage to running 386 code on an Inboard with only
16-bit memory.  It works and it's cheap, though, so you can always upgrade
later.

> As far as I know, none of the 386 Unix systems have any understanding of
> the fact that some memory is fast 32 bit and some is slow 16 bit.  Many
> 386 boxes have a limited amount of fast 32 bit memory which should be
> used for active text and stack segments, not the buffer cache.

I had 3mb of 16-bit memory installed in my system together with the 3mb maximum
of 32-bit memory on the Inboard; this issue was nagging me, too, especially
considering that XENIX 386 keeps everything around for as long as possible
in its object cache--that is, some data objects might get "stuck" in 16-bit
memory and never leave.  When I began to get parity errors in the 16-bit memory,
I just removed it permanently rather than finding and replacing the chips.
At least in my case, 3mb 32-bit memory is more than enough.  In an Inboard 386
system, the first 256kb of memory is the 16-bit memory on the PC/AT motherboard.
I don't know whether the "inboard" keyword on the boot string, i.e.,
"hd(40)xenix inboard" takes that memory into account (it DOES turn on 16mhz
mode and cache.)

I agree that it would be nice to have a system which could recognize these
two "classes" of memory, if only to determine what the magnitude, if any,
of the improvement might be.  It would be amusing if the side-effect of
locating the buffer cache in 16-bit memory was to slow the entire system
down (I don't know that, of course, but I never fail to be surprised how
"intuitive" assumptions can be shown incorrect.)

Anyway, here is a reposting of my test results:
---------------------------------------
All tests were run on the same hardware and software environment,
with the exception of the replacement of the 286 for the 386 card,
under SCO XENIX 286 OS v. 2.1.3 with Development System v. 2.1.4
or SCO XENIX 386 OS and Development System beta test with beta update (6/16/87).

	      IBM PC/AT 8mhz	  IBM PC/AT with Intel Inboard 386/AT
					at 16mhz, cache enabled
		XENIX 286	XENIX 286	XENIX 286	XENIX 386
		16-bit mem	16-bit mem	32-bit mem	32-bit mem

Drystone 1.1	no reg	reg	no reg	reg	no reg	reg	no reg	reg
		1084	1094	1957	1963	2906	2893	4603	4922

Buchholz (sum of user & sys times in sec)

short cpu	0.3		0.2		0.1		0.1
medium cpu	3.3		1.9		1.2		0.5
long cpu	***		*** (values out of range)	2.6
short I/O	0.9		0.6		0.4		0.1
I/O bound	3.1		1.9		1.4		0.5
long mixed	56.9		33.8		21.8		8.9

-- 
Steve Dyer
dyer@harvard.harvard.edu
dyer@spdcc.COM aka {ihnp4,harvard,linus,ima,bbn,m2c}!spdcc!dyer