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