NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/unix/xenix/sco/3550

Internet Message Format | 1992-12-28 | 5.5 KB

Xref: sparky comp.unix.xenix.sco:3550 biz.sco.general:4854
Path: sparky!uunet!consult!bob
From: [e-mail] (Bob Willey)
Newsgroups: comp.unix.xenix.sco,biz.sco.general
Subject: SCO Xenix w/SCSI Performance Testing/Results
Keywords: SCSI Adaptec
Message-ID: <[e-mail]>
Date: 28 Dec 92 02:45:22 GMT
Organization: CCS Enterprises, Inc.
Lines: 92


>        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.

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      38.8   0.2     1.6
hd0a      2k     8192    38.3    0.5   15.1      59.9   0.0    26.7
rhd0a    256k     64     25.6    0.0    3.8      36.8   0.0     1.3
hd0a     256k     64     25.6    0.0   12.9      59.6   0.0    26.5
rroot     2k     8192    26.8    0.3    5.0      38.8   0.1     1.9
root      2k     8192    34.4    0.5   15.6      59.6   0.1    26.9
rroot    256k     64     25.9    0.0    3.8      36.9   0.0     1.8
root     256k     64     25.9    0.0   13.0      59.6   0.0    26.7
rhd00     2k     8192    25.4    0.5    4.7      38.8   0.1     1.8
hd00      2k     8192    34.7    0.5   14.5      59.6   0.1    27.0
rhd00    256k     64     25.7    0.0    3.7      36.9   0.0     1.9
hd00     256k     64     27.0    0.0   13.1      59.7   0.0    27.0

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:  I got the dd program from SCO Xenix 2.3.2 (386 binary) and was
able to do 256K transfers.  There are the results included above.  Did
change some of the transfers (especially for 2k).  Hopefully I will get
the SCSICNTL.EXE from adaptex this week.  I got the phone #, but the
login: password: info was truncated, so I will await a reply.
--
>.. Bob Willey, CDP          ..  |  ..  uunet!consult!bob  [e-mail]   ..<
>.. CCS Enterprises, Inc.    ..  |  ..   Office: [phone]          ..<
>.. P.O. Drawer 1690         ..  |  ..      FAX: [phone]          ..<
>.. Easton, Maryland 21601 ......|......... BBS: [phone] ...........<