jsrobin@eneevax.UUCP (John S. Robinson) (03/12/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? > >-- >Bill Mulert UUCP: ukma!spca6 \ >Intercomputer Communications Corp. decuac!uccba > !icc!wdm >Cincinnati, Ohio 45236 mit-eddie!uccba / >(513)-745-0500 I investigated this issue very carefully before purchasing a version of Unix for my DELL 310 (a 386 machine with a 82385 cache controller) in October of 1988. The products I researched were those of Interactive, Microport, Bell Technologies, and SCO. The only product which had it's processor to memory references mediated by the 82385 cache controller when available on a 386 machine was SCO(Version 2.3.1). Bell Technologies went on to explain that the 'generic' AT&T 386 UNIX, which is essentially the same code for Interactive, Microport, and Bell Tech., actually 'programs around' the cache controller if a machine had a memory cache controller. The implication of this being that AT&T 386 UNIX perform better in a machine without a cache controller than on one with a cache controller! This implication was confimed by the Bell Tech. tech rep. Before you send flames my way I must reiterate that this was what was told to me by a Bell Technologies tech. rep. Repeated calls were made to Interative and the other vendors with essentially the same results. I emphasized to the various tech reps that my questions pertained not to the 'caching ability of the unix kernel', but refered to the intel 82385 cache controller. In each case it usually took several days and many call backs, but in the end I was able to determine that only SCO would 'claim' that they supported the 82385 cache controller. I suspect that this is one of the prime reasons that it is taking SCO so dreadfully long to get there upgrade to Sys V 3.2 shipped, long after everyone else is shipping product. The real issue is though does it make a difference. If only SCO supports the 82385, then this would mean that the performance on computations that required lots of memory references should be significantly better under SCO than the others. This does seem to be the case if one believes the results of the bench marks published in the February '89 issue of MIPS magazine where ICS, Microport, SCO 2.3, and ENIX where compared on a DELL 310. Unfortunately, the benchmarking method was not done in a way that would eliminate other variables such as efficiency of the compilers used by the different systems.
dyer@spdcc.COM (Steve Dyer) (03/12/89)
In article <1581@eneevax.UUCP> jsrobin@eneevax.eng.umd.edu (John S. Robinson) writes: > In each case it usually took several days and many call backs, but in > the end I was able to determine that only SCO would 'claim' that they > supported the 82385 cache controller. I suspect that this is one of the > prime reasons that it is taking SCO so dreadfully long to get there > upgrade to Sys V 3.2 shipped, long after everyone else is shipping > product. The only reason I can imagine why SCO isn't shipping UNIX V 3.2 yet is because they have to provide an environment which is compatible with their earlier releases. Microport (rip?), Interactive and AT&T could essentially start from a "blank slate" of 386 customers or those who are already familiar with System V.3 on other architectures. SCO cares enough to worry about all its customers running its earlier releases who will be adding new machines and upgrading older ones. UNIX V/386 3.2 out of the box just won't hack it alone--binary compatibility is only a small part of keeping an operation running which already has staff trained on the way SCO XENIX has been administered and has been used. Their 2.3 release is a transitional move towards complete integration. The stuff about "programming around" the cache controller in the other flavors of UNIX sounds pretty spurious to me. I would be VERY surprised if CPU-bound programs compiled on either a XENIX 386 box or a 386/ix box or an AT&T 3.2 box (choose one) showed different execution times on identical machines with cache (with only the OS differing.) Sounds easy to test, though. -- Steve Dyer dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer dyer@arktouros.mit.edu
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (03/14/89)
In article <1581@eneevax.UUCP> jsrobin@eneevax.eng.umd.edu (John S. Robinson) writes: [ about SCO using cache, V.3 "programming around" it ] | Unfortunately, the benchmarking method was not done in a way | that would eliminate other variables such as efficiency of the | compilers used by the different systems. The way to try this would be to compile a program on V/386 and Xenix, and run both executables on both machines. They claim that works, right? This would provide some insight into the situation. If I had to bet, I'd say that there's not going to be a difference other than the compiler performance. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me