From: bob@consult.UUCP (Bob Willey CDP)
Newsgroups: biz.sco.general
Subject: Re: Performance issues revisited
Date: 23 Dec 92 17:07:50 GMT
Reply-To: bob@consult.UUCP (Bob Willey CDP )
Organization: CCS Enterprises, Inc. - Easton, MD

>        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)
> SCO Xenix 2.3.2                        SCO Xenix 2.3.4 GT
>                  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.

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.


NOTE:  Where do you get the above utility???? ^^^^^^^  SCSICNTL.EXE
       I have looked on Adatpec's BBS, Seagate's, Quantum's, and ours
       and did not find this utility.  Also checked several other BBS's
       and could not locate it.

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.  

  sh$ time dd if=/dev/DEVICE of=/dev/null bs=BLOCKSIZE count=COUNT
  (BLOCKSIZE * COUNT = 16MB)

Results:
                        -----Old System------  -----New System------
DEVICE BLOCKSIZE COUNT  REALTIME USER  KERNEL  REALTIME USER  KERNEL
====== ========= =====  ======== ====  ======  ======== ====  ======
rhd0a     2k     8192    25.4    0.2    5.0     1:06.2  0.0    3.1
hd0a      2k     8192    38.3    0.5   15.1       59.0  0.2   27.0
rhd0a    256k     64     25.6    0.0    3.8        N/A
hd0a     256k     64     25.6    0.0   12.9        N/A
rroot     2k     8192    26.8    0.3    5.0     1:06.1  0.0    3.7 
root      2k     8192    34.4    0.5   15.6       58.8  0.1   27.5
rroot    256k     64     25.9    0.0    3.8        N/A
root     256k     64     25.9    0.0   13.0        N/A
rhd00     2k     8192    25.4    0.5    4.7     1:07.1  0.0     4.1
hd00      2k     8192    34.7    0.5   14.5       58.8  0.2    27.1
rhd00    256k     64     25.7    0.0    3.7        N/A
hd00     256k     64     27.0    0.0   13.1        N/A

Interpretation:
Real conclusions: you'd better run some extensive tests like this before
you can even begin to understand the transfer rate characteristics of
your disk & CPU combination -- and that's only one small part of
characterizing the overall performance of your disk subsystem.

Note:  You will notice on the New System (SCO Xenix 2.3.4) the dd
command gave us an error:  dd: argument 256K out of range
Tried doing 64k and also 262144, but no luck.  Obviously something
is still not setup correctly on the NEW SCSI-2 system with the
Adaptec 1542B controller.  We really need to get our hands on the
SCSICNTL.EXE program so we can see what is going on.
Thanks for everyone's help and assistance.
-- 
>.. Bob Willey, CDP          ..  |  ..  uunet!consult!bob  bob@ccs.com   ..<
>.. CCS Enterprises, Inc.    ..  |  ..   Office: (410) 820-4670          ..<
>.. P.O. Drawer 1690         ..  |  ..      FAX: (410) 476-5261          ..<
>.. Easton, Maryland 21601 ......|......... BBS: (410) 476-5098 ...........<