Date: Mon, 27 Sep 1999 13:56:09 -0600 (MDT) From: "Kenneth D. Merry" <ken@kdm.org> To: groudier@club-internet.fr (Gerard Roudier) Cc: street@iname.com (Kevin Street), scsi@FreeBSD.ORG Subject: Re: sym driver 0.3.0 Message-ID: <199909271956.NAA38933@panzer.kdm.org> In-Reply-To: <Pine.LNX.3.95.990927211018.392A-100000@localhost> from Gerard Roudier at "Sep 27, 1999 09:20:23 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
[ reply moved to the bottom, where replies belong ]
Gerard Roudier wrote...
> On 27 Sep 1999, Kevin Street wrote:
> > Gerard Roudier <groudier@club-internet.fr> writes:
> >
> > > I have made available revision 0.3.0 of the sym_hipd driver for
> > > FreeBSD-CAM. This driver version behaves correctly on QUEUE FULL
> > > condition and has been rock solid for me.
> >
> > > Latest revision:
> > > sym-0.3.0-1990925
> >
> > I decided to give this a try on an ASUS SC-875 (since I don't have an
> > 896) to see what it would do. It's stable and seems to give similar
> > performance to the ncr driver on make buildworld's (src on scsi, obj on ide).
> >
> > It's about 30% slower than the ncr driver with dump however.
> > I was dumping from file systems on da1 to files on da0
> > (a syquest syjet removable scsi).
> >
> > The sym driver gave me about 1125 - 1250 KBytes per second throughput.
> > The ncr driver gave about 1550 - 1725 KBytes per second as reported by
> > dump. I tried these dumps a couple of times each with similar
> > numbers. These are medium size (400M - 750M) dumps. Small file systems
> > (eg root) were closer in speed with a slight edge to the ncr.
[ ... ]
> You test is not serious. If you only can provide 1.5MB/second throughput
> for a benchmark of SCSI driver, please go away or make comparison with an
> AHA 1542. I consider your posting to be a bad joke and hope that it is not
> intentionnaly just bad taste.
I don't think it's a joke at all. dump is a reasonable real-world
benchmark -- it's something that people run every day.
In any case, the issue with dump isn't necessarily the throughput, but
rather the number of transactions. dump is notoriously slow, for a variety
of reasons. It tends to involve a high number of seeks. Here's an example
from the first stage of a dump off of a ccd array consisting of 2 18G
Seagate Cheetah II's:
ccd0 da0 da1 da2
KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s
8.00 994 7.76 8.00 49 0.38 8.00 521 4.07 8.00 472 3.69
8.00 1010 7.89 0.00 0 0.00 8.00 487 3.81 8.00 523 4.08
8.00 1012 7.91 0.00 0 0.00 8.00 489 3.82 8.00 523 4.08
8.00 1015 7.93 0.00 0 0.00 8.00 492 3.84 8.00 523 4.08
8.00 1015 7.93 0.00 0 0.00 8.00 492 3.84 8.00 523 4.08
8.00 1009 7.88 0.00 0 0.00 8.00 486 3.80 8.00 523 4.08
8.00 980 7.66 0.00 0 0.00 8.00 473 3.70 8.00 507 3.96
8.00 1008 7.88 0.00 0 0.00 8.00 487 3.81 8.00 521 4.07
8.00 1008 7.88 0.00 0 0.00 8.00 491 3.84 8.00 517 4.04
8.00 1015 7.93 0.00 0 0.00 8.00 491 3.84 8.00 524 4.09
8.00 1015 7.93 0.00 0 0.00 8.00 491 3.84 8.00 524 4.09
8.00 994 7.77 8.00 6 0.05 8.00 479 3.74 8.00 515 4.02
8.00 1014 7.92 0.00 0 0.00 8.00 491 3.84 8.00 523 4.08
8.00 1015 7.93 0.00 0 0.00 8.00 491 3.84 8.00 524 4.09
8.00 1015 7.93 0.00 0 0.00 8.00 491 3.84 8.00 524 4.09
8.00 999 7.81 8.00 2 0.02 8.00 483 3.78 8.00 516 4.03
8.00 985 7.70 1.67 3 0.00 8.00 475 3.71 8.00 510 3.98
8.00 987 7.71 0.00 0 0.00 8.00 479 3.74 8.00 508 3.97
8.00 995 7.77 0.00 0 0.00 8.00 481 3.76 8.00 514 4.01
8.00 988 7.72 0.00 0 0.00 8.00 477 3.73 8.00 511 3.99
ccd0 da0 da1 da2
KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s
8.00 996 7.78 0.00 0 0.00 8.00 483 3.77 8.00 513 4.01
8.00 996 7.78 0.00 0 0.00 8.00 483 3.78 8.00 513 4.01
8.00 994 7.77 0.00 0 0.00 8.00 479 3.74 8.00 515 4.02
8.00 988 7.72 0.00 0 0.00 8.00 479 3.74 8.00 509 3.98
Now that's a fair number of transactions per second, and certainly not a
bad benchmark of drive and controller performance.
Later stages of the dump don't go as fast, since they don't necessarily do
everything in 8K chunks. Here is sample iostat output from stage 4 of the
same dump on the same system:
ccd0 da0 da1 da2
KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s
4.66 623 2.84 0.00 0 0.00 4.76 301 1.40 4.58 322 1.44
3.85 381 1.43 0.00 0 0.00 3.73 195 0.71 3.97 186 0.72
3.99 434 1.69 0.00 0 0.00 3.85 188 0.71 4.10 246 0.98
4.32 447 1.88 0.00 0 0.00 4.39 226 0.97 4.24 221 0.91
4.56 597 2.66 0.00 0 0.00 4.56 287 1.28 4.57 310 1.38
4.70 892 4.09 0.00 0 0.00 4.69 446 2.04 4.70 447 2.05
4.72 804 3.71 0.00 0 0.00 4.70 377 1.73 4.73 427 1.97
4.69 958 4.38 0.00 0 0.00 4.69 474 2.17 4.68 483 2.21
4.73 811 3.74 0.00 0 0.00 4.70 410 1.88 4.75 401 1.86
4.71 796 3.66 0.00 0 0.00 4.72 409 1.89 4.69 387 1.77
4.70 969 4.45 0.00 0 0.00 4.73 474 2.19 4.67 495 2.26
4.63 593 2.68 0.00 0 0.00 4.58 317 1.42 4.69 276 1.26
4.71 861 3.96 0.00 0 0.00 4.68 435 1.99 4.73 427 1.97
4.71 871 4.01 0.00 0 0.00 4.66 440 2.00 4.75 432 2.00
So the transaction counts vary widely, and the average throughput isn't
all that great for a pair of drives that can otherwise do at least 30MB/sec
together. But the number of transactions is still fairly high.
I think what you may want to do is ask Kevin to give you some comparisons
of iostat output from dumps with the ncr driver and dumps with the sym
driver, so you can compare how many average transactions per second happen
in each stage of the dump with each driver. That might shed light on
whether there are any significant performance differences between the
drivers.
Ken
--
Kenneth Merry
ken@kdm.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909271956.NAA38933>