Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 23 Jul 1999 10:47:27 -0700 (PDT)
From:      "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
To:        dgilbert@velocet.ca (David Gilbert)
Cc:        yusufg@outblaze.com (Yusuf Goolamabbas), freebsd-scsi@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG
Subject:   Re: Postmark results with DPT RAID-5
Message-ID:  <199907231747.KAA88500@gndrsh.aac.dev.com>
In-Reply-To: <14232.30911.431405.352467@trooper.velocet.ca> from David Gilbert at "Jul 23, 1999 10:14:23 am"

next in thread | previous in thread | raw e-mail | index | archive | help
> >>>>> "Yusuf" == Yusuf Goolamabbas <yusufg@outblaze.com> writes:
> 
> Yusuf> Hi, I am trying to stress test a DPT RAID controller DPT
> Yusuf> SmartRaid Ultra PM3334UW (Is there any standard mechanism or a
> Yusuf> methodology available for this). Any way, I am using the
> Yusuf> benchmark tool "Postmark" written by Network Appliance which is
> Yusuf> available via the URL
> Yusuf> http://www.netapp.com/technology/level3/3022.html.
> 
> I configured a DPT-3334UW on a K6-II/400 machine with 4 9G SCSI
> drives.  I found that for creating and deleting files, it couldn't be
> beat (Ports would untar 4 times faster, for instance).  However, I
> found that a single 9G on a 2940UW would easily beat the raw
> throughput.  I was dissapointed with this.

This disparity is usually caused by the configuration of the stripe size
or chunk factor set up for the raid array.  Most default raid controller
parameters are optimized for tps (transactions per second) not for
aggregate data transfer rates.

And an ever larger problem in optimizing raid arrays for raw throughput
is the need to spindle sync the drives, with correct RPL Offsets, such
that the SCSI commands and data can blast out the channel at full speed
without incurring rotational delay per drive/chunk of transfer.  This
process requires a SCSI bus analyzer, logic analyzer and a lot of patients!


-- 
Rod Grimes - KD7CAX - (RWG25)                    rgrimes@gndrsh.dnsmgr.net


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




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