From: belal@sco.COM (Bela Lubkin)
Newsgroups: biz.sco.general
Subject: Re: Performance issues revisited
Date: 23 Dec 92 02:15:29 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Precedence: bulk

My own results:

Machine: A.I.R. 486/33EL (EISA) motherboard, 36MB RAM, 256K cache, Lark
ESDI controller, HP 660MB ESDI drive (not sure of model #), using
non-translated parameters.

Basic command:

  ksh$ time dd if=/dev/DEVICE of=/dev/null bs=BLOCKSIZE count=COUNT

  (BLOCKSIZE * COUNT = 16MB)

Results:

  DEVICE        BLOCKSIZE    COUNT    REALTIME    USER TIME    KERNEL TIME
  ==========    =========    =====    ========    =========    ===========
  /dev/rhd0a       2k         8192      82.35       0.00          0.16
  /dev/hd0a        2k         8192      15.91       0.48         10.95
  /dev/rhd0a      256k         64       15.57       0.00          1.97
  /dev/hd0a       256k         64       15.52       0.01          8.65
  /dev/rroot       2k         8192      81.88       0.00          0.15
  /dev/root        2k         8192      15.87       0.57         10.89
  /dev/rroot      256k         64       16.25       0.00          1.83
  /dev/root       256k         64       15.67       0.01          8.19
  /dev/rhd00       2k         8192      83.49       0.02          0.30  (*1)
  /dev/hd00        2k         8192      16.15       0.54         11.00  (*1)
  /dev/rhd00      256k         64       15.73       0.03          1.92  (*2)
  /dev/hd00       256k         64       15.68       0.02          8.64  (*2)

(*1) iseek=11520, to avoid bad blocks on the drive
(*2) iseek=90, to avoid bad blocks on the drive

Interpretation:

The test transferred 16MB (16777216 bytes) of data.  The fastest time
was 15.52 seconds, or 1081006 bytes/sec.  The drive has 57
sectors/track, or 29184 bytes/track.  Assuming 3600rpm (which may be too
low), or 60 revolutions/second, it should be able to transfer 1751040
bytes/second.  So clearly it's not catching every revolution.  On the
other hand, I may be pushing the limits of the AT bus's ability to do
programmed I/O (the ESDI driver does not use DMA -- ISA DMA is
pathetically slow).

In all cases, transferring 2K at a time through a raw device was slow.
Clearly, here, my disk controller was not doing the track caching it's
advertised to do, and the trip from user program to kernel and back was
long enough to miss revolutions of the disk.

2K at a time through the block device was nearly as fast as large
blocks, probably because the kernel was doing read-ahead.  Pushing 2K at
a time through the buffer cache incurred a lot of kernel overhead, but
not enough to slow down the overall time -- this would not have been
true if my process had been competing with a CPU-intensive process or if
my CPU had been much slower.

256K at a time was fast, but again the CPU overhead of using the buffer
cache was apparent.

I re-ran the /dev/hd0a and /dev/root suites with my CPU cache turned off
(external cache still enabled).  Most of the CPU times were
approximately doubled.  Real times for 2k-raw were about the same, since
they were not limited by the CPU.  Transfer times for everything else
were about 35% slower, indicating more missed revolutions.

Now I wonder how I turn on that supposed track cache on the controller
card?!

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.

>Bela<