performance with LSI SAS 1064

[Kenneth D. Merry]

The "tagged openings now ..." message was hidden under bootverbose by
Jordan 8 years ago. :)

So it won't show up on the console, unless you boot with -v.

Ken

On Thu, Aug 30, 2007 at 08:52:51 -0600, Scott Long wrote:
> 54MB/s is reasonable for 10k 2.5" disks.  You might be able to squeeze
> some more performance by upgrading to FreeBSD 7.0.  I _do_not_ recommend
> playing with the queue depth controls unless your console logs are
> getting quickly filled with messages about it.
> 
> Scott
> 
> 
> Lutieri G. wrote:
> >This is my disks:
> >
> >Seagate Savvio(ST913401ss) 10K.1 SAS 3Gb/s 73-GB Hard Drive. In the
> >manual file i found this information:
> >
> >Queue tagging (up to 64 queue tags supported)
> >
> >Is this the max # for setting using camcontrol?! syntax like this:
> >camcontrol tags da0 -N 64 ??
> >
> >2007/8/30, Eric Anderson <anderson at freebsd.org>:
> >>Scott Long wrote:
> >>>Lutieri G. wrote:
> >>>>2007/8/30, Eric Anderson <anderson at freebsd.org>:
> >>>>>I'm confused - you said in your first post you were getting 3MB/s, 
> >>>>>where
> >>>>>  above you show something like 55MB/s.
> >>>>Sorry! using blogbench i got 3MB/s and 100% busy. Once is 100% busy i
> >>>>thinked that 3MB/s is the maximum speed. But i was wrong...
> >>>%busy is a completely useless number for a anything but untagged,
> >>>uncached disk subsystems.  It's only an indirect measure of latency, and
> >>>there are better tools for measuring latency (gstat).
> >>>
> >>>>>You didn't say what kind of disks, or how many, the configuration, etc 
> >>>>>-
> >>>>>so it's hard to answer much.  The 55MB/s seems pretty decent for many
> >>>>>hard drives in a sequential use state (which is what dd tests really).
> >>>>>
> >>>>SAS disks. Seagate, i don't know what is the right model of disks.
> >>>>
> >>>>Ok. If 55Mb/s is a decent speed i'm happy. I'm getting problems with
> >>>>squid cache and maybe should be a problem related with disks. But...
> >>>>i'm investigating and discharging problems.
> >>>>
> >>>>
> >>>>>Your errors before were probably caused because your queue depth is set
> >>>>>to 255 (or 256?) and the adapter can't do that many.  You should use
> >>>>>camcontrol to reduce it, to maybe 32.  See the camcontrol man page for
> >>>>>the right usage.  It's something that needs setting on every boot, so a
> >>>>>startup file is a good place for it maybe.
> >>>>>
> >>>>Is there any way of get the right number to reduce?!
> >>>>
> >>>If you're seeing erratic performance in production _AND_ you're seeing
> >>>lots of accompanying messages on the console about tag depth jumping
> >>>around, you can use camcontrol to force the depth to a lower number of
> >>>you're choosing.  This kind of problem is pretty rare, though.
> >>Scott, you are far more of a SCSI guru than I, so please correct me if
> >>this is incorrect.  Can't you get a good estimate, by knowing the queue
> >>depth of the target(s), and dividing it by the number of initiators?  So
> >>in his case, he has one initiator, and (let's say) one target.  If the
> >>queue depth of the target (being the Seagate SAS drive) is 128 (see
> >>Seagate's paper here:
> >>http://www.seagate.com/staticfiles/support/disc/manuals/enterprise/savvio/Savvio%2015K.1/SAS/100407739b.pdf
> >>), then he should have to reduce it down from 25[56] to 128, correct?
> >>
> >>With QLogic cards connected to a fabric, I saw queue depth issues under
> >>heavy load.
> >>
> >>Eric
> >>
> >>
> >>
> >>
> >>
> >
> >
> 
> _______________________________________________
> freebsd-scsi at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
> To unsubscribe, send any mail to "freebsd-scsi-unsubscribe at freebsd.org"

-- 
Kenneth Merry
ken at kdm.org