From: belal@sco.COM (Bela Lubkin)
Newsgroups: biz.sco.general
Subject: Re: Performance issues revisited
Date: 22 Dec 92 20:34:32 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Cc: uunet!consult!bob@sco.COM
Precedence: bulk

Bob Willey wrote:

> >        time dd if=/dev/rhd0a of=/dev/null bs=2048 count=8192

>        OLD MACHINE                             NEW MACHINE
> 386/33 w/8mb memory 64kcache           486/DX266 w/16mb memory 256k cache
> Ultrastor 12F ESDI controller          Adaptec 1542 SCSI controller
> Maxtor 338mb drive (~ 16ms)            HP 667 SCSI-2 drive (~13ms)
> CMS Enhancement 250mb tape             Archive ST-525 mb tape (SCSI)
>                        Results of above command:
> Real 25.3  user 0.3  sys 5.2           real 1:01.6  user 0.3  sys 3.6
>                  Tape backup results when using CTAR
> Typical:  2.3mb/min                    Typical:  5.8mb/min
> 
> While the backup time is noticeable faster, the dd command for disk transfer
> appears noticeable SLOWER on the new machine???  Is there anything obvious
> in the above configuration that can cause problems?  Is there anything
> special that needs to be done to the Adaptec controller to get better
> performance??  This is very uncomforting since we are upgrading to obtain
> more throughput.

Even the slower hard disk transferred 16MB/min. in the `dd` test, so
obviously even a fast tape drive is a bottleneck.  Your backup speed
difference is due to the tape drives used, 'nuff sed.  

The SCSI disk may have an internal cache which needs special SCSI
commands to enable (get Roy Neece's SCSICNTL.EXE to mess with that, but
be Vewwy Caewful -- write down *everything* about the drive's current
configuration before setting it to a nonfunctional set of parameters!
I've thoroughly toasted myself once with SCSICNTL)  Many SCSI drives
have such caches, and for reasons I've never been able to fathom,
they're usually disabled from the factory.

Relative seek times aren't likely to make a noticable difference.  Most
disks spin at 3600rpm (or the same order of magnitude), which is 16.67ms
per revolution.  Obviously you can't get the data off a track faster
than one revolution.  Also, you're reading consecutive tracks, so you're
getting the "track-to-track" (fastest), not the average seek time.  The
drives might be 4ms vs. 3ms in track-to-track, making only a 1ms
difference out of ~20ms per track, optimum.  That's if the drive doesn't
lose revolutions.  Much more important is the number of physical
512-byte sectors per track on the drive.  Ignore the translated
parameters, get out the drive manuals and look up physical sectors/track
when formatted 512 bytes/sector; and also rotational speed.  From these
you can work out the fastest possible transfer rate off the disk.

Transfer rates are extremely sensitive to block sizes, and sometimes to
raw device vs. block device, and (this one is weird) your results may be
VERY different when accessing the whole-partition device (/dev/hd0a) vs.
a division device (/dev/root), which is how you most likely normally
access your data.  So, try the following variations on both machines.
Make a table of the results.  Post it.

  time dd if=/dev/rhd0a of=/dev/null bs=2k count=8192 (original flavor)
  time dd if=/dev/hd0a of=/dev/null bs=2k count=8192  (blk device)
  time dd if=/dev/rhd0a of=/dev/null bs=256k count=64 (raw device, large blk)
  time dd if=/dev/hd0a of=/dev/null bs=256k count=64  (blk device, large blk)

  time dd if=/dev/rroot of=/dev/null bs=2k count=8192 (divvy device, raw)
  time dd if=/dev/root of=/dev/null bs=2k count=8192  ( ", blk)
  time dd if=/dev/rroot of=/dev/null bs=256k count=64 ( ", raw, large blk)
  time dd if=/dev/root of=/dev/null bs=256k count=64  ( ", blk, large blk)

  time dd if=/dev/rhd00 of=/dev/null bs=2k count=8192 (whole-disk, raw)
  time dd if=/dev/hd00 of=/dev/null bs=2k count=8192  ( ", blk)
  time dd if=/dev/rhd00 of=/dev/null bs=256k count=64 ( ", raw, large blk)
  time dd if=/dev/hd00 of=/dev/null bs=256k count=64  ( ", blk, large blk)

That's 12 tests * 2 machines, have fun!  ;-}  Note that the third set
will FAIL on the ESDI drive if there are any bad sectors in the first
16MB of the drive.  To avoid this you could eyeball your badtrk table,
try to figure out where a 16MB swath of good disk exists, then use
"iseek=#", where #=how many 2k or 256k blocks to skip to get to the good
area; or you could reduce the total size and interpolate results, but be
absolutely sure that the total transfer size is at least one block size
larger than your buffer cache.  DO NOT USE "skip=#"!!  That has a
totally different effect: "iseek=" lseek's in the file; "skip=" *reads*
that much data before beginning the transfer, which will 1) still trip
on the bad sectors, and 2) totally hose your timings.

>Bela<