Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 25 Jul 1997 00:06:44 -0700 (PDT)
From:      Simon Shapiro <Shimon@i-Connect.Net>
To:        Jaye Mathisen <mrcpu@cdsnet.net>
Cc:        scsi@FreeBSD.ORG, hackers@FreeBSD.ORG
Subject:   RE: Ugh, DPT killing my performance... :(
Message-ID:  <XFMail.970725000644.Shimon@i-Connect.Net>
In-Reply-To: <Pine.NEB.3.95.970724164859.19992Q-100000@mail.cdsnet.net>

next in thread | previous in thread | raw e-mail | index | archive | help

Hi Jaye Mathisen;  On 24-Jul-97 you wrote: 
> 
> 
> P6-200, 64MB RAM, DPT 2 channel Ultra Wide, plugged in to Seagate
> Barracuda's.  (4GB).  DPT has 64MB RAM, version 1.10 DPT patch,
> 2.2.2-RELEASE disk.  All disks are on the same channel (0) of the DPT.
> 
> The following script renders the system essentially unusable:
> 
> while (1)
> 
>   (cd t1 && iozone 600)
>   (cd t2 && iozone 600)
>   bonnie -s 200 &
> 
>   wait
> end
> 
> 
> ls -l of /root takes > 20 seconds.  
> 
> TOP is showing > 99% idle time.
> 
> systat 2 only shows 28 interrups/sec on IRQ 15, which is the DPT
> controller, according to the BIOS.  Transfers shows about 20-30 tps.


Ah, This is it!  Take the DPT off that IRQ15.   On a P6-200 I am peaking 
at 1,200 tps, kernel make is about 400, make world 300 or so.
On many motherboards IRQ 15 is a garbage can for all sorts of stray signals.
If you compiled with DPT_MEASURE_PERFORMANCE;

  mknod  /dev/dpt0 c 130 0
  echo -n "dump softc" > /dev/dpt0
  get_dpt /dev/dpt0 > /tmp/foo

Now look at the output.  The second line, tells you the count of aborted
interrupts, spurious interrupts, minimum interrupt latelncy and maximum
interrupt latency.

The third line lists each SCSI command number, name [section in the spec],
minimum time to executre, maximum time to execute.

The fourth line tells you maximim/minimum waiting time, submitted time,
completed time.

The next line tells you the number of times commands collided in the driver,
# of times the DPT was too busy to accept a command, worst # of retries, 
best # of retries.

These will tell us where the DPT + driver are spending their time.
Corrective action can then be suggested.

> There are these occasional burps of > 20% system time, not sure where
> it's
> going.
> 
> No other processes actively running.
> 
> 
> This concerns me a bit.

concerns me A LOT :-)


> I tried the same thing on a 3 disk ccd array, and it runs much smoother,
> w/o the long delays.  Of course, no parity.

> The DPT is configured as RAID-5, 128k stripes.  Other than the grief of
> installing it, not sure how much benefit there would be to changing this.

Why grief?  I am planning on a new dptmgr for FreeBSD, so your comments
are valuable to me.

Simon



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.970725000644.Shimon>