cjeffery@arizona.edu (Clinton Jeffery) (08/16/89)
Could the use of 16-bit extended memory be a problem running Sys V/386, aside from the speed penalty (which ought to be mitigated by a caching motherboard)? Thanks, Clint -- | Clint Jeffery, U. of Arizona Dept. of Computer Science | cjeffery@arizona.edu -or- {noao allegra}!arizona!cjeffery --
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (08/16/89)
>Could the use of 16-bit extended memory be a problem running >Sys V/386, aside from the speed penalty (which ought to be mitigated >by a caching motherboard)? It should not be a problem. Does anyone have a benchmark as to what 16 bit memory does to performance if you have a caching motherboard? I'm quite interested since it's the only way I can add memory. -- Branch Technology | zeeff@b-tech.ann-arbor.mi.us | Ann Arbor, MI
laurie@ucscb.UCSC.EDU (60648000) (08/17/89)
In article <9639@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >Does anyone have a benchmark as to what 16 bit memory does to performance >if you have a caching motherboard? I'm quite interested since it's the >only way I can add memory. I was running a AST premium 386/20 with 2.6mb of 32 bit memory. I then added a 2mb 16 bit 100 ns memory card and when running graphics programs that malloc'ed HUGE data structures (1-2 mb), my box ran about 40-60 % slower. I was really suprised at the diff. Ken Chapin
tron1@tronsbox.UUCP (K.J.Jamieson) (08/18/89)
>>Could the use of 16-bit extended memory be a problem running >>Sys V/386, aside from the speed penalty (which ought to be mitigated >>by a caching motherboard)? I am running 2 meg of 32 bit ram and 3 of 16bit ---- the 16 is at 2 wait states and is a hassle, but very inexpensive. It runs FINE! -- A >GOOD< cache system (like the EVEREX) will ofset this a lot. **************************************************************************** * " Salad isn't food, salad is what food eats. " The Zen Monk ALF * * "My thoughts claim no responsibility for my body" * * UUCP: tron1@tronsbox.UUCP uunet!mimsy!oddjob!clout!ddsw1!tronsbox!tron1 * * Sysop, the Penthouse ]I[ BBS * * (201)759-8450 (201)759-8568 * ****************************************************************************
karl@ficc.uu.net (karl lehenbauer) (08/21/89)
In article <8746@saturn.ucsc.edu>, laurie@ucscb.UCSC.EDU (60648000) writes: > In article <9639@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: > >Does anyone have a benchmark as to what 16 bit memory does to performance > >if you have a caching motherboard? I'm quite interested since it's the > >only way I can add memory. > I was running a AST premium 386/20 with 2.6mb of 32 bit memory. I then added > a 2mb 16 bit 100 ns memory card and when running graphics programs that > malloc'ed HUGE data structures (1-2 mb), my box ran about 40-60 % slower. > I was really suprised at the diff. But does it have a cache? On a Mylex 386/16, 32-bit reads that are cache misses incur two wait states, 16-bit reads that are cache misses incur five wait states, cache hits are zero wait states. They claim the cache hit rate (cache only helps on reads; writes must still be written, although I think writes only incur one wait state) is typically 80%. This should mean (in the "typical" sceniaro) that 20% of the reads take 2.5 times longer with 16-bit memory rather than 32. I realize benchmarks would be a lot more useful. I'd like a way to differentiate between the 32-bit and 16-bit memory and use them for different purposes. You could isolate your 16-bit memory from Unix simply by not making its address start contiguously with the end of your 32-bit memory. The only way I have figured out to make use of that without the Unix source (or a lot of pain) is to use it as a ramdisk. It would be really nice if you could get Unix to use it for disk buffers, tho' again a pain without the source. -- -- uunet!ficc!karl "Have you debugged your wolf today?"
dave@micropen (David F. Carlson) (08/22/89)
In article <8746@saturn.ucsc.edu>, laurie@ucscb.UCSC.EDU (60648000) writes: > > I was running a AST premium 386/20 with 2.6mb of 32 bit memory. I then added > a 2mb 16 bit 100 ns memory card and when running graphics programs that > malloc'ed HUGE data structures (1-2 mb), my box ran about 40-60 % slower. > I was really suprised at the diff. > > Ken Chapin A wish list item of mine is to be able to dedicate certain memory ranges for the el-cheapo 16 bit memory to be used for LARGE, inexpensive buffer cache memory. Ken is quite correct that the large number of WS kill kernel and user space performance but having 4-8 meg of buffer cache would be much faster than 350K in cache. (Besides which, buffer writes from disk or user space take a performance hit to 32bit cached memory because of write-through strategies anyway. (Write-back will have a cache write that will be line buffered; not as bad but still not great.) -- David F. Carlson, Micropen, Inc. micropen!dave@ee.rochester.edu "The faster I go, the behinder I get." --Lewis Carroll
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (08/24/89)
> >I'd like a way to differentiate between the 32-bit and 16-bit memory and use >them for different purposes. You could isolate your 16-bit memory from If the Unix vendors would just start allocating memory from the top so that the disk buffers and kernel would end up in 16 bit memory, things would work much better. Seems like a simple change - how about it Interactive? -- Branch Technology | zeeff@b-tech.ann-arbor.mi.us | Ann Arbor, MI
darryl@ism780c.isc.com (Darryl Richman) (08/25/89)
In article <9642@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >>I'd like a way to differentiate between the 32-bit and 16-bit memory and use >>them for different purposes. You could isolate your 16-bit memory from > >If the Unix vendors would just start allocating memory from the top so that >the disk buffers and kernel would end up in 16 bit memory, things would work >much better. Seems like a simple change - how about it Interactive? MEMRANGEs marked with `:1' in your /etc/default/boot file are used preferentially for the kernel, since the mark indicates that the memory cannot be DMAed. Don't expect your disk buffers to end up there, however. --Darryl Richman -- Copyright (c) 1989 Darryl Richman The views expressed are the author's alone darryl@ism780c.isc.com INTERACTIVE Systems Corp.-A Kodak Company "For every problem, there is a solution that is simple, elegant, and wrong." -- H. L. Mencken
pcg@aber-cs.UUCP (Piercarlo Grandi) (08/25/89)
In article <9642@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: > >I'd like a way to differentiate between the 32-bit and 16-bit memory and use >them for different purposes. You could isolate your 16-bit memory from If the Unix vendors would just start allocating memory from the top so that the disk buffers and kernel would end up in 16 bit memory, things would work much better. Seems like a simple change - how about it Interactive? I have not tried, but it may well be that by opportune tweaking of the memory range line in /etc/default/boot one could achieve this. If, as might well be, the kernel looks at memory in the same order as the ranges are given in the memory ranges line, that is. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
karl@ficc.uu.net (Karl Lehenbauer) (08/29/89)
In article <9642@b-tech.ann-arbor.mi.us>, zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: > If the Unix vendors would just start allocating memory from the top so that > the disk buffers and kernel would end up in 16 bit memory, things would work > much better. Seems like a simple change - how about it Interactive? I for one would not want the kernel in 16-bit RAM. I would still like to see more explicit control, using the 16-bit RAM (on my system at least) for disk cache and maybe a ramdisk. -- -- uunet!ficc!karl "Have you debugged your wolf today?"