From: drew@ophelia.cs.colorado.edu (Drew Eckhardt) Subject: Re: Abysmal disk performance Date: Fri, 15 May 1992 22:10:13 GMT
In article <1992May14.010044.15762@gateway.novell.com> norsk@mobius (Doug Thompson) writes:
>In article <1992May13.234457.29352@colorado.edu>,
>drew@ophelia.cs.colorado.edu (Drew Eckhardt) writes:
>> The string instructions (ie portread / portwrite in hd.c) are abysmally slow
>> in comparison to DMA. The same can be said for strcpy(). We should
>> modify the hd.c code, etc to use DMA to a track sized buffer, and DMA in
>> memory to memory mode to copy to the identity mapped buffercache.
>>
>> The same can be used to copy pages where both pages < 16M.
>>
>> I will start on this code after we get into our new apartment, and have
>> the data sheets out, or someone mails me a reference on the 8237's in
>> the AT.
>
>As I remember the 8237 DMA clicks along at 3 Mhz on the original AT
>coupled with
>10-15 wait states. I don't know how many wait states used on 386 boxes today
>but I believe the DMA is still at 3Mhz. Starting with the 286 and beyond
>doing a REP INS would transfer at bus speed.
>
That's because the DMA chip ran at 1/2 processor clock.
My system (33 Mhz 386, very generic) can be set to run at 1/2 processor
clock or 1 X processor clock (16.5 or 33 Mhz), configurable for
between 1 and 4 waitstates.
>The DMA circuits on the AT just could not provide very fast transfers, thus
>the POLL input on the WD controller and childern. That is why Adaptec went
>with the DMA master model. The 1542 would utilize the DMA handshake lines
>itself and not use the on board 8237's.
Also, if the DMA is initiated by the adapter board, it can steal
bus cycles, whereas if the DMA is controlled by an onboard DMA chip,
the processor can't get any other work done.
>I might be out of date, but thats what I remember from days working on 286s
>and early 386s
From what I've seen, this isn't the case anymore. Anyways, I'll finish this
and do some performance tests afterwards.