Path: utzoo!attcan!lsuc!maccs!cs4g6ag From: cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) Newsgroups: comp.sys.ibm.pc Subject: Re: Track caching hard disk controllers Message-ID: <2581DCC8.2180@maccs.dcss.mcmaster.ca> Date: 10 Dec 89 04:34:16 GMT References: <767@jwt.UUCP> Reply-To: cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) Organization: McMaster University, Hamilton, Ontario Lines: 31 In article <767@jwt.UUCP> john@jwt.UUCP (John Temples) writes: $ [...] Does this mean that a track is still read $in in a single disk revolution regardless of the interleave, and that $writes are not cached? For the track reading, the limiting factor that makes interleave adjustment necessary for optimum performance is not the interface between the bard disk and the controller, but rather that between the controller and the processor's memory. The disk controller should be able to handle all seventeen sectors at once and store them in memory, so interleave shouldn't make a difference to read times. As for writes ... it sounds like the controller uses a write-through cache, which means that data is written to the disk as soon as you send it, rather than when it's convenient. This would still be affected by interleave, as the controller has to wait until the correct sector is passing under the head before it can write. Write-through caches are more reliable in situations where there may be a power failure at any time, since it ensure that your data is written to the disk immediately (well, pretty much). However, it would improve write times significantly to queue disk write requests on the controller board. There is still one thing, though, that is odd - the decrease in disk write performance even without changing interleave. I can't think of any reason why that would happen. -- Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca = "\nI'm only an undergraduate!!!\n"; **************************************************************************** If it's true that love is only a game//Well, then I can play pretend