Xref: utzoo comp.unix.internals:1535 comp.unix.sysv386:3144 Path: utzoo!attcan!lsuc!eci386!jmm From: jmm@eci386.uucp (John Macdonald) Newsgroups: comp.unix.internals,comp.unix.sysv386 Subject: Re: The performance implications of the ISA bus Message-ID: <1990Dec17.174220.2174@eci386.uucp> Date: 17 Dec 90 17:42:20 GMT References: <18871@yunexus.YorkU.CA> Reply-To: jmm@eci386.UUCP (John Macdonald) Organization: Elegant Communications, Inc. Lines: 58 In article pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: |rreiner> Would their advantages go away if they were used in the setup |rreiner> you suggest (since you claim that one would get effectively |rreiner> near-zero seek times anyway)? | |Track buffering is not a property of ESDI controllers alone; some |popular RLL controllers also have track buffering. Track buffering reads |an entire track when you read or write a sector on that track. This is |only a win if you access consecutively several sectors in the same |track, otherwise it is a lose because it forces you to wait for an |entire revolution to read a sector, when on average only a third/half |would be enough. With old style filesystems, which are fragmented fairly |easily, this is usually not a win, especially for writes; I have turned |off track buffering on my RLL controller. It is instead a definite win |if you use the various styles of Fast File System, as they usually |succeed in keeping logically consecutive sectors physically contiguous |as well, and in doing multi sector requests. | |Note that track buffering only influences rotational latency, not seek |latency. It is possible to set up a controller to give most of the benefit of track buffering without any possible loss. Have the controller do the following when attempting to read a sector: seek to the right track, start reading sectors. When the desired sector has been read process it (send it to CPU using the appropriate DMA and so on and then interrupt the CPU to terminate the IO; while this is being done continue to read the track and save each sector that is read into the track buffer. Keep a record of which sectors have been read and which haven't. Whenever the CPU's device driver handles the IO completion it will likely issue another request. When a request comes to the controller, check to see if it can be satisfied from any available buffered track. If so, do that and don't interfere with any disk reading that is still going on filling a track buffer. If not, terminate any ongoing track buffer activity for a different track and seek to the desired track, and start buffering. When the background processing is able to finish reading a track buffer and there is still no new request that requires a real disk access, then additional background activity can be done (complete filling a track buffer that has been partially filled, read a new track when many of the sectors in the previous track have been used, write out any buffered changed sectors if write-through is not being used, etc.). Since this procedure returns a result as soon as it is available, and start to process a new request as soon as it is issued, there is no loss; it is just that there is the potential for using the sectors that come under the read head during rotational latency, and in using the time between host requests, and in using the time saved by filling a host request from a track buffer. Off hand, I don't know whether any particular disk controller uses this algorithm, but I wouldn't be surprised if one did. It does require that the controller be able to do some activities simultaneously (DMA, IO completion, and new activity startup with the host; all at the same time as IO processing to the disk.) -- Cure the common code... | John Macdonald ...Ban Basic - Christine Linge | jmm@eci386