wdm@icc.UUCP (Bill Mulert) (03/06/89)
There are now a number of high performance 80386 motherboards in use in personal computers. Some of these machines have the Intel cache controller chip, and 32 to 64k of 30ns ram. Cacheing software for MsDos is available for those users. My question is, is this cache controller usaeble by any of the Unix - Xenix kernels? Does'nt the kernel have to know about it in order to use it? Do any of Microport, SCO, Interactive support the chip? Would one be wasting ones money to buy a machine with a cache controller that would be running Xenix? -- Bill Mulert UUCP: ukma!spca6 \ Intercomputer Communications Corp. decuac!uccba > !icc!wdm Cincinnati, Ohio 45236 mit-eddie!uccba / (513)-745-0500
dyer@spdcc.COM (Steve Dyer) (03/06/89)
In article <195@icc.UUCP> wdm@icc.UUCP (Bill Mulert) writes: >There are now a number of high performance 80386 motherboards in >use in personal computers. Some of these machines have the Intel >cache controller chip, and 32 to 64k of 30ns ram. Cacheing software >for MsDos is available for those users. So-called "cacheing software" under DOS is usually (not always) referring to "DOS hard disk cacheing software". This is not relevant to the memory cache controller (a piece of hardware) nor is it useful or relevant when UNIX or any OS other than DOS is running. >My question is, is this cache controller usaeble by any of the >Unix - Xenix kernels? Does'nt the kernel have to know about it >in order to use it? OK. That would almost always be a BIOS issue, really. A reasonable machine powers up cache enabled, with some keyboard strokes to manipulate cache on/off or and perhaps the speed of the machine. Once XENIX or UNIX is running, it needn't touch this (and once it's running you can't use the BIOS keystroke method of manipulating it because the BIOS isn't used after booting under UNIX.) So, if you can force the cache on from the keyboard, you should then be able to boot UNIX or XENIX with no special support in the kernel. Now... the Intel Inboard 386/AT is a 386 card for the PC AT which powers up in "8mhz cache on" when you really want "16mhz cache on". It comes with DOS software to manipulate the 4 possible combinations. But, XENIX 386 has a special boot keyword which diddles the right IO ports to get the desired behavior. Even in its absence, it's simple to manipulate /dev/port in an /etc/rc startup script to get the right behavior. It could be that other motherboards behave in a similar fashion. You'd need to read the technical manual for the motherboard (provided it came with one--good luck!) -- Steve Dyer dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer dyer@arktouros.mit.edu
jbayer@ispi.UUCP (Jonathan Bayer) (03/06/89)
In article <195@icc.UUCP> wdm@icc.UUCP (Bill Mulert) writes: >There are now a number of high performance 80386 motherboards in >use in personal computers. Some of these machines have the Intel >cache controller chip, and 32 to 64k of 30ns ram. Cacheing software >for MsDos is available for those users. > >My question is, is this cache controller usaeble by any of the >Unix - Xenix kernels? Does'nt the kernel have to know about it >in order to use it? Do any of Microport, SCO, Interactive >support the chip? Would one be wasting ones money to buy a >machine with a cache controller that would be running Xenix? You are talking about two types of cache here. The caching software is mainly disk cache software, used to speed up access to the hard disk (and sometimes the floppy). Good disk caching software can make a slow drive look much faster, and a fast drive look almost instantaneous. The Intel cache controller and the cache ram (as well as other hardware caches) are used as memory caches. The software has no knowledge of it, and usually has no need to know. The only real exception is software that is extremely time-dependent, such as copy-protection software. Any operating system will take advantage of the hardware cache. These caches work by relying on the fact that 1. Memory accessed once will usually be accessed again, usually very soon. 2. As a general rule memory is usually accessed in a fairly sequential order. In other words, when the first byte of an instruction is being loaded in to the cpu the cache will be fetching the next byte in memory in anticipation of the cpu. Typical caches will have a hit rate of between 80 and 90 percent. The higher the hit rate the fewer wait states the cpu will have to endure, and the faster the system throughput. Not being a hardware guru I am sure that I have left out a few facts, but the overall idea is complete. JB -- Jonathan Bayer Beware: The light at the end of the Intelligent Software Products, Inc. tunnel may be an oncoming dragon 19 Virginia Ave. ...uunet!ispi!jbayer Rockville Centre, NY 11570 (516) 766-2867 jbayer@ispi.UUCP
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (03/07/89)
In article <195@icc.UUCP> wdm@icc.UUCP (Bill Mulert) writes: | My question is, is this cache controller usaeble by any of the | Unix - Xenix kernels? Does'nt the kernel have to know about it | in order to use it? Do any of Microport, SCO, Interactive | support the chip? Would one be wasting ones money to buy a | machine with a cache controller that would be running Xenix? I think you confuse disk cache and memory cache. The only reason to turn cache off is if it's broken or you want the machine to have prro performance. If you want good performance memory cache will help, particularly if you run some slow memory cards with wait states. Cache isn't a substitute for fast memory, but it will buy you 30% or so in CPU performance. Note: 30% claim based on Dhrystone 1.0 on a 16MHz AMI motherboard. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
rob@phavl.UUCP (Robt. I. Ransbottom) (03/07/89)
In article <195@icc.UUCP>, wdm@icc.UUCP (Bill Mulert) writes: > use in personal computers. Some [...386] machines have the Intel > cache controller chip, and 32 to 64k of 30ns ram. > > My question is, is this cache controller usaeble by any of the > Unix - Xenix kernels? Does'nt the kernel have to know about it > in order to use it? Do any of Microport, SCO, Interactive > support the chip? Would one be wasting ones money to buy a The kernels of Microport & Interactive Unix do not have difficulty with the cached memory. I don't think Xenix would either. This is pretty transparent to *ix. BUT: Where you may have some difficulty is with a machine which runs all (usu. 16meg.) memory through the cache. An example is the Dell 310. If there is not a way to disable the caching of a Meg or so of the address space you may have problems getting an intelligent i/o board to work. (The cache sees no reason to pass the data to/from the memory space the board is using.) I hear that the same problem occurs with dumb boards. -- ...!uunet!phavl!rob Robert Ransbottom
trebor@biar.UUCP (Robert J Woodhead) (03/07/89)
While we are on the subject of caches, is there a cache board that will
plug into Tandy 4000{LX} machines to improve their performance?
+---------------------------------------------------------------------------+
| Robert J Woodhead !uunet!cornell!biar!trebor CompuServe 72447,37 |
| Biar Games, Inc., 10 Spruce Lane, Ithaca NY 14850 607-257-1708,3864(fax) |
+---------------------------------------------------------------------------+
| Games written, Viruses killed "I'm the head honcho of this here spread; |
| While U Wait. Take a number. I don't need no stinking disclaimers!!!" |
+---------------------------------------------------------------------------+jcm@mtunb.ATT.COM (was-John McMillan) (03/08/89)
In article <2727@spdcc.SPDCC.COM> dyer@ursa-major.spdcc.COM (Steve Dyer) writes: >In article <195@icc.UUCP> wdm@icc.UUCP (Bill Mulert) writes: >>There are now a number of high performance 80386 motherboards in >>use in personal computers. Some of these machines have the Intel >>cache controller chip, and 32 to 64k of 30ns ram. Sounds good. >> Cacheing software >>for MsDos is available for those users. Sounds possible... maybe improbable, but possible. >>My question is, is this cache controller usaeble by any of the >>Unix - Xenix kernels? Does'nt the kernel have to know about it >>in order to use it? Sanity still prevails.... >OK. That would almost always be a BIOS issue, really. A reasonable >machine powers up cache enabled, with some keyboard strokes to manipulate >cache on/off or and perhaps the speed of the machine. Once XENIX or >UNIX is running, it needn't touch this (and once it's running you can't >use the BIOS keystroke method of manipulating it because the BIOS isn't >used after booting under UNIX.) So, if you can force the cache on from >the keyboard, you should then be able to boot UNIX or XENIX with no special >support in the kernel. >[... u.s.w.] Whaattt? Well, things never have been the same since the flu' hit. Maybe the ol' brain's out the door for good. Well, thinking about it, my brain's DEFINITELY gone since I'm responding to a XENIX(rg) issue and haven't seen that sucker for YEARS... but... Caches usually require kernel software for: 1) Boot-time checkout (validation); 2) Defective cache shutdown/workaround; 3) Context-switch flushing; 4) Memory-mapped hardware cache-BLOCKING; 5) DMA-overlapped page flushing/blocking; 6) Text-loading cache-flushing (split text & data caching); 7) ... ok, my recollections are fading.... For some systems soem of the above features would be irrelevant. Yup. Just TURN ON THE CACHE AND RUN. The kernel doesn't need to know a thing about the particular cache you're using -- it uses the phase of the moon and LORAN to work out the details. As alluded to earlier, Bill, I can't answer if XENIX is written to include support for the Intel cache. It certainly COULD test for its existence -- and run in "defective cache" mode if the cache were absent. But, as blithered above, I'm still dizzy from the flu'. jcm -- att!mtunb!jcm -- juzz muttering... sorry... HackCoughHack
mhlevy@sbee.sunysb.edu (Mark Levy) (03/09/89)
In article <195@icc.UUCP>, wdm@icc.UUCP (Bill Mulert) writes:
# There are now a number of high performance 80386 motherboards in
# use in personal computers. Some of these machines have the Intel
# cache controller chip, and 32 to 64k of 30ns ram. Cacheing software
# for MsDos is available for those users. ^^^^^^^^^^^^^^^^
THe caching software is
disk-caching. To the best of
my knowledge, this is the only
type available
# My question is, is this cache controller usaeble by any of the
# Unix - Xenix kernels? Does'nt the kernel have to know about it
# in order to use it? Do any of Microport, SCO, Interactive
# support the chip? Would one be wasting ones money to buy a
# machine with a cache controller that would be running Xenix?
There is a general misconception in the computing public, which is divided
into two groups... People who have worked on large systems, and those who
haven't. Those who haven't mistake software disk-caching for the kind of
cache provided in hardware (and this isn't helped by software companies'
advertisements). The typical disk cache reserves a portion of memory (not
the cache memory found on the motherboard) to store more than just the requested
information from the disk. Since DRAM is much faster than the fastest ESDI
drives available, this serves to speed disk access.
The hardware cache provided by manufacturers is memory cache. It serves
to speed up the access of main memory. This allows very fast processors to
use slower DRAM without having to add wait-states.
According to SCO, the XENIX kernal is able to take advantage of the on-
board cache. I am no 386 guru, but I imagine that the hardware would make
the use of the cache transparent to the system software. (Please note: I got
the information from an SCO sales rep)
For a terrific explanation of cache, see this month's BYTE magazine.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mark Levy { mhlevy@sbccvm.BITNET } % DISCLAIMER??? HA!!!
{ mhlevy@sbee.sunysb.edu } % I admit it! Go ahead, blame me,
{ mhlevy@ccvm.sunysb.edu } % everyone else does!!!!news@brian386.UUCP (Wm. Brian McCane) (03/17/89)
In article <1425@mtunb.ATT.COM> jcm@mtunb.UUCP (was-John McMillan) writes: > Caches usually require kernel software for: > 1) Boot-time checkout (validation); > 2) Defective cache shutdown/workaround; > 3) Context-switch flushing; > 4) Memory-mapped hardware cache-BLOCKING; > 5) DMA-overlapped page flushing/blocking; > 6) Text-loading cache-flushing (split text & data caching); > 7) ... ok, my recollections are fading.... > To quote Bill Murray "Whooooa nice shootin' there Tex!" But I'm a little concerned as to it's accuracy. Admitted I don't do hardware or Unix kernels for a living, but I know a little. Cache checking should be done in the power up routines just like the keyboard. And if it is defective, the system probably won't boot, since I believe cache off on most systems means it doesn't cache, instead it just passes the data blindly. From what I remember of the specs (their at work, I'm not :-), the cache doesn't care about the context or any such noise. Instead, it keeps track of the absolute address requested by the '386, and can retrieve the date in 16 byte blocks, for later use. The data is kept using an modified Least Recently Used algorithm. The biggest problem, is that some operations such as compressing/decompressing files, or any operations where large amounts of PHYSICAL RAM are used reduce the caches usefulness to 0. Any access by the CPU to ram including swaps to disk (I'm not sure about DMA but I think it works too), are simply kept track of and the new contents that are stored in these locations is used. brian -- Wm. Brian McCane | Life is full of doors that won't open | when you knock, equally spaced amid Disclaimer: I don't think they even | those that open when you don't want admit I work here. | them to. - Roger Zelazny "Blood of Amber"
jcm@mtunb.ATT.COM (was-John McMillan) (03/21/89)
Probably the best advice on this topic was to read a recent [PC-mag., Byte?] article on this particular cache. I did, and I DIDN'T re-submit clarifications. SBC's note suggests some are needed. (I'll also point out that I believe I stated up front that I was NOT addressing THIS cache directly as I hadn't seen the spec's on it.) In article <422@brian386.UUCP> news@brian386.UUCP (Wm. Brian McCane) writes: >In article <1425@mtunb.ATT.COM> jcm@mtunb.UUCP (was-John McMillan) writes: >> Caches usually require kernel software for: >> 1) Boot-time checkout (validation); Nothing in the article indicated any validation is performed. >> 2) Defective cache shutdown/workaround; Nothing in the article indicated any shutdown mechanism is available. >> 3) Context-switch flushing; This cache is placed between Mem Manager and Phys Mem: it looks at Phys Memory only. (Placing an cache where it reads Virtual Memory addresses is probably a pretty stupid thought on my part.) >> 4) Memory-mapped hardware cache-BLOCKING; Nothing in the article indicated any mechanism is provided to permit memory-mapped hardware addresses. This would be gross. More information is needed. >> 5) DMA-overlapped page flushing/blocking; One of this caches features is that it monitors the Physical Mem Address lines and disqualifies any entries it contains for DMA-addressed memory. >> 6) Text-loading cache-flushing (split text & data caching); (Ref: (3) above. This point is irrelevant if physical memory is cached.) ... >Cache checking should be done in the power up routines just like the >keyboard. And if it is defective, the system probably won't boot, >since I believe cache off on most systems means it doesn't cache, instead >it just passes the data blindly. Some systems can run with their cache disabled. AT&T has even distributed benchmarks of their machines where they'd forgotten to enable the cache: ouch! (Generates some embarrassingly low throughput numbers.) jc mcmillan -- att!mtunb!jcm