Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!cbmvax!daveh From: daveh@cbmvax.UUCP (Dave Haynie) Newsgroups: comp.arch Subject: Re: SRAM vs. DRAM, 33MHz 386 UNIX-PC Message-ID: <7851@cbmvax.UUCP> Date: 7 Sep 89 16:57:00 GMT References: <21936@cup.portal.com> Organization: Commodore Technology, West Chester, PA Lines: 106 in article <21936@cup.portal.com>, cliffhanger@cup.portal.com (Cliff C Heyer) says: > 1. UNIX (or any multitasking OS) and the effects of > the on-board cache: > While multitasking, does flushing the cash waste a measurable amount > of run time or is it insignificant compared to swapping, paging, and/or > other overhead? Generally, UNIX system do cache flushes when they enter kernel space, and they MUST between user tasks, since the address spaces are aliased. Caching still helps under UNIX, maybe even considerably depending on the main memory design, but you won't get the maximum possible performance out of a system under UNIX. Check out MIPS magazine, they tend to benchmark '386 systems under a variety of UNIX derivitives and raw (program loaded in '386 native mode from MS-DOS); the raw case always performs better. Of course, chances are, a benchmarking program will likely fit entirely in a 32k or 64k cache. You have to ask yourself if a little better raw speed is enough to drive you from UNIX to MS-DOS :-). Another issue may be disk drive speed. On the 68030 systems I work on, I've seen hard disk speed drop by a factor of 2-3 when going from our native OS to UNIX. I'm not sure any '386 PCs have fast enough disk hardware for this to make a difference, but it could. > 2. Is memory technology (cost/speed ) lagging behind microprocessor > technology? Undoubtedly. Try running a 50MHz '030 (real, sitting next to me on my desk here) without wait states on any memory. > 3. Is it impractical (cost and/or size) to put 40 256KB 25ns SRAMs (no > refresh overhead and cycle time=access time) up for main memory? Yes. First, it'll cost a big bundle. Second, I don't think you really want to run UNIX with only 1 megabyte of real memory; I've found it's really not what I'd call comfortably fast without about 4 megabytes, at least on our 68030 systems. > In other words, is it cheaper to implement paged (PMRAM, SCRAM) or > interleaved schemes to reduce wait states rather than use 40 SRAMs? By far. > It seems like alot of trouble to go to...but how much do SRAMs cost? I think they're somewhere on the order of 5x the cost for the same amount of memory, and they also take up at least twice the board space. Also, SRAM densities are a generation or so behind DRAM densities (256k x 4 SRAMs are almost as easy to come by today as 1 Meg x 4 DRAMs). > 4. Are any board makers making (or have made) motherboards with ESDI and/or > SCSI interfaces ON BOARD to bypass the 8MHz AT bus? Even that's not enough. SCSI, for example, is still only 8 bits wide, and it's maximum transfer rate of 4 megs/second is in the same ballpark as the fastest AT buses. That's all a secondary issue as long as you're multitasking; the real concern is how long disk I/O ties up the main bus. The best thing to do here is read a reasonable number of bytes over the SCSI bus into a FIFO, then transfer that data over you're full bus width via DMA (another reason to avoid the AT bus). This is what Amiga hard disk controllers do, and we get up to 900k/sec through the filesystem using asynchronous SCSI (1.5 megs/sec). I've heard of PC systems (ALR I think) that get around 750k/sec, I suspect they do something clever. > 6. If you whipped out your trusty soldering gun and anti-static gear and > changed all your memory chips to 25 ns SRAMS(on a 33MHz machine w/no cache) > would the wait states go away? Well, first of all, they woundn't physically fit. You'd really have to throw out the whole memory subsystem. There's undoubtedly some logic that sets the memory cycle time. And on top of that, even if the memory did fit, there's no guarantee that a DRAM bus which cycles in 140ns would still work with SRAM and 40ns cycles times. > 7. The PC manufacturers never talk about parity error checked memory, Most PCs use partity checked memory, which lets them detect a memory error (and increases the chance of such an error by 1/9), but doesn't let them do anything about it. > Harvard A.(separate data/instruction cache), This isn't an advantage as an external cache unless you're CPU has external I and D busses. The only one I know of that does is the Motorola 88100. While 68030s have an internal Harvard design with separate I and D caches, the '386 doesn't have any internal caching. While it's no problem for UNIX, apparently MS-DOS would have some great trouble with split caches, which is the main reason given for the unified cache built into the 80486 (though I suspect the other reason is that Intel might rather sell you a different chip for non-PC applications, so it wouldn't do to make the 80486 overly fast, would it...). > Are PC mfgs behind the times? Or is this because of all the canned stuff > from the east. Most of the canned stuff comes from California chip fabs. And I suspect many PC makers are behind the times. The rest of them are struggling with the architecture. > >operates FCC class B. Whaddya expecting, miracles?!? -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough