piety@hplred.HP.COM (Bob Piety) (03/12/91)
Does anyone know of the availability of a driver that hooks into DOS and lets DOS and, hence, application programs communicate to a SCSI hard disk via DMA? It sure is sad to to see a high-performance 386 or 486 spinning its wheels while a disk head seeks to a given track..... Any pointers would be appreciated. Bob piety@hplred.hpl.hp.com (415)857-4759
vail@tegra.COM (Johnathan Vail) (03/13/91)
In article <27080001@hplred.HP.COM> piety@hplred.HP.COM (Bob Piety) writes: Does anyone know of the availability of a driver that hooks into DOS and lets DOS and, hence, application programs communicate to a SCSI hard disk via DMA? The DMA on an AT is much slower than the equivelent loop in software. The DMA is there mostly for the refresh, I believe. If DMA is used then the bios for the disk would have the "driver" and DOS would still wait for the IO to complete. It sure is sad to to see a high-performance 386 or 486 spinning its wheels while a disk head seeks to a given track..... What *else* would a PC running DOS be doing? DOS is not multitasking and if a program is waiting for data from the disk then it waits for that data. Now if you were running unix.... jv "Everything that gives us pleasure gives us pain to measure it by." -- The Residents, GOD IN THREE PERSONS _____ | | Johnathan Vail | n1dxg@tegra.com |Tegra| (508) 663-7435 | N1DXG@448.625-(WorldNet) ----- jv@n1dxg.ampr.org {...sun!sunne ..uunet}!tegra!vail
piety@hplred.HP.COM (Bob Piety) (03/15/91)
/ vail@tegra.COM (Johnathan Vail) / 9:11 am Mar 12, 1991 / > In article <27080001@hplred.HP.COM> piety@hplred.HP.COM (Bob Piety) writes: > Does anyone know of the availability of a driver that hooks into DOS > and lets DOS and, hence, application programs communicate to a SCSI > hard disk via DMA? > The DMA on an AT is much slower than the equivelent loop in software. > The DMA is there mostly for the refresh, I believe. If DMA is used > then the bios for the disk would have the "driver" and DOS would still > wait for the IO to complete. True. But the machine in question is an HP Vectra 486, with an EISA bus that is capable of 33 MHZ DMA rates, and the controller is an Adaptec 1740 HBA capable if the same data rates. > It sure is sad to to see a high-performance 386 or 486 spinning its > wheels while a disk head seeks to a given track..... > What *else* would a PC running DOS be doing? DOS is not multitasking > and if a program is waiting for data from the disk then it waits for > that data. Agreed-- but in this case, I want to *write* a block of data to the disk, and not wait around while it does so, freeing the 486 for much-needed, real-time data monitoring. I see the point you make, but it seems that it would be a relatively simple matter to create a driver that would permit DMA writes and only hold off the CPU if attempts were made to access the same buffer, no? Or is that too much to do under DOS? > Now if you were running unix.... I'm seriously considering it! But the additional cost and learning curve make it less attractive at the moment. That's why I'm hoping for an easier solution for this specific problem, short of having to write directly to the HBA, and maintaining my own (DOS-incompatible) file structure, or duplicating DOS structure. I *do* appreciate your comments, but I'm surprised that there doesn't seem to be an off-the-shelf solution for DOS. Thanks, Bob piety@hplred.hpl.hp.com (415)857-4759
sph@logitek.co.uk (Stephen Hope) (03/15/91)
vail@tegra.COM (Johnathan Vail) writes: >In article <27080001@hplred.HP.COM> piety@hplred.HP.COM (Bob Piety) writes: > Does anyone know of the availability of a driver that hooks into DOS > and lets DOS and, hence, application programs communicate to a SCSI > hard disk via DMA? >The DMA on an AT is much slower than the equivelent loop in software. >The DMA is there mostly for the refresh, I believe. If DMA is used >then the bios for the disk would have the "driver" and DOS would still >wait for the IO to complete. > It sure is sad to to see a high-performance 386 or 486 spinning its > wheels while a disk head seeks to a given track..... >What *else* would a PC running DOS be doing? DOS is not multitasking >and if a program is waiting for data from the disk then it waits for >that data. >Now if you were running unix.... >jv This is not strictly true. DMA is not as fast as an I/O loop, but the latency between a request for transfer and response for DMA is on the order of 1uS or less. I/O loop transfers are only "better" for peripherals with a buffer (so that latency is less important), and where transfers are block oriented, ie each transfer moves a large amount of data. For example, older LAN cards with no buffering (eg 3Com 3C501) only work well if DMA is used - Yes I know this is an opinion, so no flames. I can also think of examples where DMA is better, eg where disk to tape backups are taking place. If DMA is used for disk to memory and tape to memory transfers, then the processor can just supervise the whole process. I believe something like this is used by DOS backup packages. Stephen >"Everything that gives us pleasure gives us pain to measure it by." > -- The Residents, GOD IN THREE PERSONS > _____ >| | Johnathan Vail | n1dxg@tegra.com >|Tegra| (508) 663-7435 | N1DXG@448.625-(WorldNet) > ----- jv@n1dxg.ampr.org {...sun!sunne ..uunet}!tegra!vail
jesup@cbmvax.commodore.com (Randell Jesup) (03/23/91)
In article <sph.669040581@krypton> sph@logitek.co.uk (Stephen Hope) writes: >vail@tegra.COM (Johnathan Vail) writes: >>The DMA on an AT is much slower than the equivelent loop in software. >>The DMA is there mostly for the refresh, I believe. If DMA is used >>then the bios for the disk would have the "driver" and DOS would still >>wait for the IO to complete. ... >>What *else* would a PC running DOS be doing? DOS is not multitasking >>and if a program is waiting for data from the disk then it waits for >>that data. >This is not strictly true. DMA is not as fast as an I/O loop, but the >latency between a request for transfer and response for DMA is on the >order of 1uS or less. I/O loop transfers are only "better" for peripherals >with a buffer (so that latency is less important), and where transfers >are block oriented, ie each transfer moves a large amount of data. For >example, older LAN cards with no buffering (eg 3Com 3C501) only work well >if DMA is used - Yes I know this is an opinion, so no flames. The only reason DMA isn't as fast (or is no faster) than the CPU on an AT-type machine is that the DMA is normally not bus-mastering DMA (it uses those silly programmed DMA-things on the motherboard). Bus-mastering DMA should always be faster than the processor (given reasonable design), since the data need only cross the bus once instead of twice with a processor loop (read data, stuff in memory - ignoring instruction overhead). Of course on a single-tasking machine it might not make any difference if the processor can read data and store it faster than it comes off the device. DMA is a BIG win with a multitasking machine, since the processor often does have better things to do than poll I/O ports. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)