larry@tapa.uucp (Larry Pajakowski) (07/11/89)
We recently put an ADAPTEC 1540A SCSI into a Compaq 386/20 as a second disk controller using 2.3.2GT. The first contoller is the Compaq supplied WD1007. Performance on the SCSI disks are worse (I'm being kind) than were expected. Here are some performance numbers all in kb/sec.: disk raw device block device large file ESDI 340 319 288 SCSI 107 57 56 The ESDI is a Compaq supplied 300mb Minisribe and the SCSI disks (2) are CDC Wren IV also 300mb. The ESDI file system is fairly new and the SCSI file system is virgin. BTW the correlation of block device to large file is worth noting in light of the benchmarks published here a week or so ago. I tried reformatting with adfmt but got an error. Also the 1540A was jumpered for both sync and async negotiation with no change. Anybody have any ideas? Thank's Larry Pajakowski ...ddsw1!tapa!larry
carlson@scooter.UUCP (Joe Carlson) (07/11/89)
In article <1989Jul10.175106.11166@tapa.uucp>, larry@tapa.uucp (Larry Pajakowski) writes: > > We recently put an ADAPTEC 1540A SCSI into a Compaq 386/20 as a second disk >...... > disk raw device block device large file > SCSI 107 57 56 The ~60 Kbyte/second looks a lot like read a block/skip a revolution/ read a block.... You might try changing the filesystem gap parameter. [mkfs parameter].
debra@alice.UUCP (Paul De Bra) (07/12/89)
In article <1989Jul10.175106.11166@tapa.uucp> larry@tapa.uucp (Larry Pajakowski) writes: > >We recently put an ADAPTEC 1540A SCSI into a Compaq 386/20 as a second disk >controller using 2.3.2GT. The first contoller is the Compaq supplied WD1007. >Performance on the SCSI disks are worse (I'm being kind) than were expected. >Here are some performance numbers all in kb/sec.: > > disk raw device block device large file > > ESDI 340 319 288 > > SCSI 107 57 56 > >The ESDI is a Compaq supplied 300mb Minisribe and the SCSI disks (2) are CDC >Wren IV also 300mb. The ESDI file system is fairly new and the SCSI file >system is virgin. BTW the correlation of block device to large file is worth >noting in light of the benchmarks published here a week or so ago. >... The symptom you have is most likely a gapsize problem. Most disks spin at about 3600rpm, or 60 rotations per second. I assume the size of blocks in the file system is 1k. If the interleaving is too small you have to wait for a whole rotation to get the next disk-block. This results in a throughput of 60*512 = 30kbytes per second. (disk blocks are only 512 bytes) Since you get more than 30 kbytes per second we can assume the interleaving is correct. If the gapsize is too small (a parameter when creating file systems) you have to wait for a whole rotation after every file system block, which results in a throughput of 60kbytes per second. The actual throughput is a bit less since after a whole rotation you are back were you started from, and not yet at the next file system block, which is a bit further away. If you have 35 disk-blocks on one track and use 1:1 interleaving then the next block is at lease 2/35 of a rotation away. The correct gapsize is something you have to find out by experimenting. On an ESDI drive with a 1:1 interleave and full-track buffer there may be several values that result in the same performance (due to the buffer). So the default value may have been right for the ESDI controller from the start. For a controller without a full-track buffer (i assume your SCSI controller is like that) you have to search for the exact value. If the value is too small you get the extremely low throughput you have measured. Increasing the value will result in a jump to a very high throughput at the correct value. Increasing the value further will result in a gradual decrease in throughput as you introduce unnecessary rotational delay. Hope this helps. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
rickf@netcom.UUCP (Rick Francis) (07/12/89)
In article <1989Jul10.175106.11166@tapa.uucp> larry@tapa.uucp (Larry Pajakowski) writes: > >We recently put an ADAPTEC 1540A SCSI into a Compaq 386/20 as a second disk >controller using 2.3.2GT. The first contoller is the Compaq supplied WD1007. >Performance on the SCSI disks are worse (I'm being kind) than were expected. >Here are some performance numbers all in kb/sec.: > > disk raw device block device large file > > ESDI 340 319 288 > > SCSI 107 57 56 > >The ESDI is a Compaq supplied 300mb Minisribe and the SCSI disks (2) are CDC >Wren IV also 300mb. The ESDI file system is fairly new and the SCSI file We also have 300MB CDC drives with the Adaptec 1540A. When we first installed the drives, we had about the same performance you're getting. We had the drive vendor re-format the drive with 1:1 interleave and enable read-ahead. We now see raw device performance of about 350 KB/SEC. Also, the REAL advantage with SCSI shows up when you have multiple drives with your I/O load balanced between them. Plus, SCSI uses less CPU time for disk transfers than ESDI. Rick Francis
neese@adaptex.UUCP (07/12/89)
>We recently put an ADAPTEC 1540A SCSI into a Compaq 386/20 as a second disk >controller using 2.3.2GT. The first contoller is the Compaq supplied WD1007. >Performance on the SCSI disks are worse (I'm being kind) than were expected. >Here are some performance numbers all in kb/sec.: > > disk raw device block device large file > > ESDI 340 319 288 > > SCSI 107 57 56 > >The ESDI is a Compaq supplied 300mb Minisribe and the SCSI disks (2) are CDC >Wren IV also 300mb. The ESDI file system is fairly new and the SCSI file >system is virgin. BTW the correlation of block device to large file is worth >noting in light of the benchmarks published here a week or so ago. > >I tried reformatting with adfmt but got an error. Also the 1540A was jumpered >for both sync and async negotiation with no change. > >Anybody have any ideas? CDC by default ships the Wren IV drives with the read ahead buffer disabled. If you enable this via the mode sense/select commands, then you will see about a 400% increase in throughput. Roy Neese Adaptec Central Field Applications Engineer UUCP @ {merch,texbell,killer}!cpe!adaptex!neese
neese@adaptex.UUCP (07/13/89)
>>Anybody have any ideas? > >CDC by default ships the Wren IV drives with the read ahead buffer disabled. >If you enable this via the mode sense/select commands, then you will see >about a 400% increase in throughput. You can also patch the kernel SCSI driver to increase the speed of the DMA on the 1542A. The default that SCO chose to use was 5MBytes/sec. This is due to the fact that some motherboards will not run any faster than that but most will run faster than that. The Tandy 4000 will run at 6.7MBytes/sec and the Tandy 4000LX will run at 8MBytes/sec. The value that needs to be changed in the 2.3GT kernel is ad_xfer. It is currently set to zero. The following table summarizes the value to the transfer rate. 0 5 MBytes/sec 1 6.7 MBytes/sec 2 8 MBytes/sec 3 10 MBytes/sec 4 5.7 MBytes/sec You need to use adb and patch the data arear at ad_xfer. Keep a good kernal around while you experiment. If the speed is too fast then you will get a parity interrupt panic as soon the the driver attempts to run the ad_init code. Nothing on the drive will be hurt, but you will need a good kernel to boot from. If possible the optimum speed should be set at 6.7MBytes/sec. This allows full SCSI bandwidth transfers in synchronous mode. Setting it much faster than that will cause the host adapter to starve the buffer on the drive and cause multiple disconnects during data transfers, even small ones such as 1K. Play around and do what is best for your system. Roy Neese Adaptec Central Field Applications Engineer UUCP @ {merch,texbell,killer}!cpe!adaptex!neese