Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!csn!kessner!david From: david@kessner.denver.co.us (David Kessner) Newsgroups: comp.sys.ibm.pc.hardware Subject: Re: Unix on 486 Machines Message-ID: <1991Jun18.090012.23059@kessner.denver.co.us> Date: 18 Jun 91 09:00:12 GMT References: <9106110417.AA06408@w20-575-117.MIT.EDU> <1991Jun11.062033.5218@kessner.denver.co.us> <1991Jun17.230100.6934@rand.org> Organization: Kessner, Inc. Lines: 65 In article <1991Jun17.230100.6934@rand.org> edhall@rand.org (Ed Hall) writes: >In article <1991Jun11.062033.5218@kessner.denver.co.us> david@kessner.denver.co.us (David Kessner) writes: >>The REAL benifit of EISA comes into play when a multitasking system is being >>used. When a UNIX task requests a block from the disk (on an ISA bus), the >>CPU goes off and grabs that block-- it takes 100% of the CPU time to get that >>block since the ISA bus and hard drive controllers are brain-dead. > >No, *some* ISA controllers are brain-dead. Not all. Ok, let me rephrase that: The restrictions that the ISA bus places on the hard drive controller makes the combination not-so-optimal. >>When an EISA based UNIX system requests a disk block, the OS tells the >>controller to read a block into memory. It then puts that task on hold >>(until the block is read in), meanwhile it goes off and runs another task. >>So, while the one task is waiting for the disk controller, others are still >>being executed-- where as an ISA based machine will pause all tasks since the >>CPU is tied up doing the disk transfer. > >Not with a bus-mastering controller. Most popular in the UNIX world >is the Adaptec 1540-series SCSI controller. This type of controller >will grab the bus and run it at full speed while the CPU goes off and >does other things. It can easily transfer data at the fastest speeds >SCSI can deliver. Bus mastering controller on an ISA bus, sure. In fact, what we all call bus mastering most comptuers call DMA. The problem is that DMA on the ISA bus is minimal at best (they are not as robust as other implamentations of DMA). In the context of ISA/EISA/MCA, the term "Bus Mastering" usually refers to the better DMA ability of the EISA/MCA bus and does not apply to the ISA bus. There is some question if DMA can go on WHILE the CPU is working. There is no real clear cut answer to this. On a 286/8 the CPU will stop during DMA, since the ISA bus and the RAM bus are the same, and the DMA will saturate the bus thus making the 286 wait. On a well designed 386/486 the ISA bus and the RAM bus are independant, and DMA from one to the other should only take up 10-30% of the RAM bus's time leaving a signifigant amount of time for the CPU. If this were the case, then your statement, above, would be correct. However, there is nothing to say that clone makers will make the board in this fashon. It is common thinking that most cleap clones only let the CPU crawl at a fraction of their original pace if not stop all together. At best, this is implamentation dependant, and something that works with one system may not be true in another. EISA, on the other hand, will ALWAYS leave the CPU running at a decent rate-- that's in the specification. Assuming that it is the case, a simple read/write to something on the ISA bus will STOP the CPU until DMA is completed. Let's say that the drive is DMA'ing and the CPU is computing. For some reason the seral card causes an intterupt (perhapse it got a character), and the CPU then tries to access the serial card but is forced to wait because DMA is chiewing up the bus. EISA fixes this by cutting down on the time the controller is on the bus (it transfers it's data in short burts rather than a continous stream that ISA's bandwidth imposes). > -Ed Hall > edhall@rand.org -- David Kessner - david@kessner.denver.co.us | 1135 Fairfax, Denver CO 80220 (303) 377-1801 (p.m.) | Reunite PANGEA! Compuserve? Isn't that some sort of FIDO BBS? |