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.questions
mailing list