[comp.unix.i386] Adaptec 1542 Kernel tuning with 386/ix

larry@nstar.uucp (Larry Snyder) (06/30/90)

I've been tuning my kernel (386/ix 3.2 2.2 release) and running
a benchmark from MIPS - and the results are interesting:

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
DD_1M2K           244K    180K    238K    277K    190K    116K
DD_1M8K           197K    277K    190K    330K    197K    256K
DD_1M17K          201K    277K    277K    218K    186K    190K
DD_5M1K           368K    274K    322K    351K    353K    351K
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
DISK-1T1X_RD      190K    293K    301K    201K    353K    379K
DISK-1T1X_WR     1280K   1280K   1280K   1280K   1280K    1280K
DISK-1T1X_RW      155K    155K    155K    153K    153K    153K
DISK-4T1X_RD      341K    379K    338K    369K    282K    286K
DISK-4T1X_WR      250K    261K    264K    254K    139K    277K
DISK-4T1X_RW       77K     76K     75K     75K     72K    77K
DISK-10T1X_RD     358K    359K    400K    366K 	  344K    372K
DISK-10T1X_WR     127K     98K     98K    106K 	   70K    121K
DISK-10T1X_RW      62K     62K     62K     61K     61K    62K
DISK-1T2X_RD      341K    366K    488K    476K    455K    500K
DISK-1T2X_WR     1463K   1463K   1463K   1463K   1463K    1463K
DISK-1T2X_RW      211K    213K    211K    209K    207K    213K
DISK-4T2X_RD      379K    374K    404K    367K    343K    392K
DISK-4T2X_WR      212K    218K    204K    212K    123K    247K
DISK-4T2X_RW       74K     74K     74K     73K     70K    75K
DISK-10T2X_RD     376K    382K    387K    332K 	  329K    377K
DISK-10T2X_WR     119K    123K    116K    120K 	   72K    124K
DISK-10T2X_RW      61K     61K     61K     60K 	   60K    62K

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.


-- 
      Larry Snyder, Northern Star Communications, Notre Dame, IN USA 
            uucp: iuvax!ndmath!nstar!larry  -or-  larry@nstar
 Public Access Unix Site (219) 289-3745 / lots of files & free PEP feeds!

behm@zds-ux.UUCP (Brett Behm) (07/04/90)

In article <1990Jun29.230754.251@nstar.uucp>, larry@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

larry@nstar.uucp (Larry Snyder) (07/04/90)

behm@zds-ux.UUCP (Brett Behm) writes:

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

I don't either.  In all cases the tests were executed on the same
location on the disk - with NOTHING else running..


-- 
      Larry Snyder, Northern Star Communications, Notre Dame, IN USA 
            uucp: iuvax!ndmath!nstar!larry  -or-  larry@nstar
 Public Access Unix Site (219) 289-3745 / lots of files & free PEP feeds!

pcg@cs.aber.ac.uk (Piercarlo Grandi) (07/05/90)

In article <1990Jul04.123903.3204@nstar.uucp> larry@nstar.uucp (Larry
Snyder) writes:

   behm@zds-ux.UUCP (Brett Behm) writes:

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

   I don't either.  In all cases the tests were executed on the same
   location on the disk - with NOTHING else running..

But you don't teel us the crucial details -- did you read from the raw
device, the block device, or from the filesystem? In the latter two
cases, how did you defeat the read-aheading. or ensured it was used, and
in the last ase, did you unmount/remount the filesystem before each read
to be sure to defeat the caching?

All over I see transfer rates around 300K per second. If they are thru
the filesystem it is not too bad, but I had expected better from
AHA1542, HPDD, and FFS. Something more like 5000-600 KB/sec.
--
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@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

larry@nstar.uucp (Larry Snyder) (07/06/90)

pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:


>But you don't teel us the crucial details -- did you read from the raw
>device, the block device, or from the filesystem? In the latter two
>cases, how did you defeat the read-aheading. or ensured it was used, and
>in the last ase, did you unmount/remount the filesystem before each read
>to be sure to defeat the caching?

File system and cache was cleared in all the benchmarks - I posted
the source code for others to see exactly what was going on.


-- 
      Larry Snyder, Northern Star Communications, Notre Dame, IN USA 
            uucp: iuvax!ndmath!nstar!larry  -or-  larry@nstar
 Public Access Unix Site (219) 289-3745 / lots of files & free PEP feeds!

poffen@sj.ate.slb.com (Russ Poffenberger) (07/06/90)

In article <PCG.90Jul5152829@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
>
>In article <1990Jul04.123903.3204@nstar.uucp> larry@nstar.uucp (Larry
>Snyder) writes:
>
>   behm@zds-ux.UUCP (Brett Behm) writes:
>
>   >I really do not know what to make of these results.
>
>   I don't either.  In all cases the tests were executed on the same
>   location on the disk - with NOTHING else running..
>
>But you don't teel us the crucial details -- did you read from the raw
>device, the block device, or from the filesystem? In the latter two
>cases, how did you defeat the read-aheading. or ensured it was used, and
>in the last ase, did you unmount/remount the filesystem before each read
>to be sure to defeat the caching?
>
>All over I see transfer rates around 300K per second. If they are thru
>the filesystem it is not too bad, but I had expected better from
>AHA1542, HPDD, and FFS. Something more like 5000-600 KB/sec.

I can get 1.3Mbytes / sec from an AHA1542B with a CDC Wren IV running dos. This
is straight disk performance, not cached. Reads and writes are about the same.


Russ Poffenberger               DOMAIN: poffen@sj.ate.slb.com
Schlumberger Technologies       UUCP:   {uunet,decwrl,amdahl}!sjsca4!poffen
1601 Technology Drive		CIS:	72401,276
San Jose, Ca. 95110             (408)437-5254

root@maxed (0000-Admin(0000)) (07/06/90)

In article <PCG.90Jul5152829@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
>
>In article <1990Jul04.123903.3204@nstar.uucp> larry@nstar.uucp (Larry
>Snyder) writes:
>
>   behm@zds-ux.UUCP (Brett Behm) writes:
>
>   >I really do not know what to make of these results.
>All over I see transfer rates around 300K per second. If they are thru
>the filesystem it is not too bad, but I had expected better from
>AHA1542, HPDD, and FFS. Something more like 500-600 KB/sec.

The BYTE UNIX Benchmarks do a 'thru the filesystem' test that is 
more illuminating, although the variance is high. I get the following
with the Adaptec AHA 1542A on a 33MHz machine running ISC 2.2:


=============================================================================
Filesystem Throughput Test:
-----------------------------------------------------------------------------
Test Time: 1 secs
                       Arithmetric        Geometric         Variance
                              Mean             Mean         (6 tests)
Read (Kbytes/sec):             2617             2050         1358965.47
Write (Kbytes/sec):             280               25         433628.17
Copy (Kbytes/sec):             1004             1000           9398.17
-----------------------------------------------------------------------------
Test Time: 10 secs
                       Arithmetric        Geometric         Variance
                              Mean             Mean         (6 tests)
Read (Kbytes/sec):              533              472          51605.47
Write (Kbytes/sec):             428              408          17707.07
Copy (Kbytes/sec):              339              336           2618.67
-----------------------------------------------------------------------------
Test Time: 20 secs
                       Arithmetric        Geometric         Variance
                              Mean             Mean         (6 tests)
Read (Kbytes/sec):              715              714           1740.27
Write (Kbytes/sec):             505              505            164.67
Copy (Kbytes/sec):              354              354            190.17

This is for the stock 5 MHz DMA and other parameters. I guess the 
variance is the result of the operating system buffering, which
is especially quirky on short tests.
-- 
 Ed Whittemore 		uunet!maxed!ed
 American Micro Group 		201 944 3293