Xref: utzoo comp.unix.internals:1419 comp.unix.sysv386:2982 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!edcastle!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.unix.internals,comp.unix.sysv386 Subject: Re: The performance implications of the ISA bus Message-ID: Date: 12 Dec 90 19:58:35 GMT References: <18871@yunexus.YorkU.CA> Sender: aro@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 84 Nntp-Posting-Host: odin In-reply-to: rreiner@yunexus.YorkU.CA's message of 11 Dec 90 15:37:41 GMT On 11 Dec 90 15:37:41 GMT, rreiner@yunexus.YorkU.CA (Richard Reiner) said: pcg> just using two ESDI controllers, one per each disk, will give pcg> tremendous improvements [because of multi-threaded operation] rreiner> What about using SCSI equipment? Do there exist SCSI host adaptors rreiner> for the ISA bus which support multi-threaded operation? Ah yes, the common recommendation is the Adaptec Host Adapter 154xB. It sings it dances, it is a floor wax and a dessert topping. Not only it is multithreaded, it does bus mastering without CPU involvement, does DMA with its won fast DMA technology, and does scatter/gather in hardware with command chaining. In other words, it is more of an IO coprocessor than a crude disk controller. The ISC HPDD exploits all its wonderful aspects. The only defect of the 1542 seems to be fairly long operation setup times, in the millisecond range, but I don't thing this is terribly important, unless you attach solid state disks to your SCSI bus. Other SCSI controllers (OMTI, Future Domain, WD FASST) may be as sophisticated, but I have no certain data. The Adaptec seems to be the most popular, and can be bought fairly cheaply from Tandy. Other drivers may be able to exploit all its wonders, (the Esix one maybe), but again I have no details. rreiner> And what about track-buffering ESDI controllers? A word of caution here: I have been reminded by William Bogstad by e-mail that there is another reason (that I had already mentioned myself long ago in comp.unix.i386) for which a multithreded controller is preferable to two ESDI ones. ESDI discs cannot do command chaining, which means that they scatter/gather has to be interrupt driven by the UNXI disc driver, not by the controller. This means that as the IO operations per second increase interupt processing overhead also increases, and can be come quite severe, because disk interrupt processing is a very high overhead activity in all 386 Unixes I know (not many). This obscene overhead could be largely obviated, like in some PDP/VAX drivers, with an interrupt processing fastpath, called pseudo-DMA in software. Maybe some 386 Unix vendor has already implemented it, but I am not aware of any. It can take several thousand instructions (milliseconds!) for an interrupt to be processed by a 386 Unix disk driver, and for a new block operation to be reissued. With IO operation rates of a several dozen per second on 4 MIPS processors this can represent a significant percentage of CPU time. For very high IO loads with many fast discs, hardware scatter/gather is very important. 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. The zero-seek-time property of three well scheduled moving arm discs moreover must be carefully understood -- it says that you get the same number of IO operations per second from 3 arms moving in parallel over 3 discs of X capacity, as you get out of a single disc with fixed heads and 3X capacity, *if* there is enough load. Note that this number of IO operations per second is lower than the number of IO operations per second from 3 discs with fixed arms, because there are two extra transfer channels than for a single disc with 3X capacity and a fixed arms. Still the speedup is impressive (but you must balance the load across the three discs!). -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk