Adaptec 1542 Kernel tuning with 386/ix

Brett Behm behm at zds-ux.UUCP
Wed Jul 4 08:47:45 AEST 1990


In article <1990Jun29.230754.251 at nstar.uucp>, larry at nstar.uucp (Larry Snyder) writes:
> I've been tuning my kernel (386/ix 3.2 2.2 release) and running
> a benchmark from MIPS - and the results are interesting:

Interesting is an understatement.
 
> CONTROLLER: ADAPTEC 1542A          DRIVE: MINISCRIBE 9380S
> MOTHERBOARD: 25MHZ '386 SOYO       RAM: 8 MEGS 80 NS 32 BIT ON MOTHERBOARD
> 
> 
> BUSS SPEED       12.5M   12.5M   12.5M   12.5M    8MHZ   12.5M
> DMA SPEED         5MHZ    6.7M      8M      8M      8M      8M
> BUSS ON/OFF        9/5     9/5     9/5     5/9    10/4    10/4
> 
> DD_1M1K           238K    284K    213K    223K    205K    223K

A DMA Speed of 8 holding bus on/off a constant is slower than 5 and 6.7?

> DD_1M2K           244K    180K    238K    277K    190K    116K

Wouldn't you think making a 2K transfer would be faster than a 1K.  All
the overhead associated with setting up the  read like arbitration, selection,
message out and in, commands, and status should be cut in half.  Unless
of course the driver is kicking in some sort of read ahead, then no difference
would be expected.  6.7 took a 100K hit - isn't that odd? 8 at 10/4 is half
as fast?

> DD_1M8K           197K    277K    190K    330K    197K    256K
> DD_1M17K          201K    277K    277K    218K    186K    190K

More unexplainable randomness.

> DD_5M1K           368K    274K    322K    351K    353K    351K

With 1M, 6.7 was the fastest, now it is the slowest with 5M.  Why would
transferring 5M in 1K chunks be any faster or slower than 1M ?

> DD_5M2K           348K    348K    363K    385K    318K    314K
> DD_5M8K           376K    348K    328K    376K    346K    356K
> DD_5M17K          358K    371K    388K    385K    288K    478K
> CP_1M             445K    488K    465K    465K    284K    539K
> CP_2M             465K    460K    460K    418K    386K    436K
> CP_5M             483K    476K    478K    459K    408K    427K

More strangeness, but less variance I guess.

> I will be posting the benchmark to the net later this evening
> (posting only to comp.unix.i386) and am looking forward to feedback
> from others running this controller with ISC 2.2.

I guess I would conclude here by saying that the above data doesn't follow
any pattern or make intuitive sense.  Was there anything else running
with the benchmark?

My studies with the adaptec 1542A show a typical 1K data transfer to take around
4.8 msec of overhead + access time + dma transfer time.  (this assumes that
the mailbox for the drive is not starved - at least 1 command pending )  
Since most drivers run the adaptec in async mode, the best transfer time we 
would expect is around 2 MB/sec.  1K would take around .5 msec, but actual 
traces show about .7 msec.  Assuming the files you are reading are sequentially
laid out on the disk, the only seek we would encounter is for the very first
transfer. This would give a flat out rate of 4.8 msec + .8 or 5.6 msec per
1K data transfer - 178K/sec.  So the driver must be performing some sort
of read ahead.  

>From what data I have gathered, DMA rate and BUSON/BUSOFF tunes really 
don't matter that much; I suppose they might become more significant as
more bus master dma's were placed on the bus (like another adaptec card).
I really doubt they can make any more than a 1-2% improvement given a 
loaded system doing primarily random access.

I really do not know what to make of these results.

Brett Behm



More information about the Comp.unix.i386 mailing list