Date: Tue, 28 Sep 1999 00:23:20 +0200 (MET DST) From: Gerard Roudier <groudier@club-internet.fr> To: "Kenneth D. Merry" <ken@kdm.org> Cc: Kevin Street <street@iname.com>, scsi@FreeBSD.ORG Subject: Re: sym driver 0.3.0 Message-ID: <Pine.LNX.3.95.990928000341.351A-100000@localhost> In-Reply-To: <199909271956.NAA38933@panzer.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello,
I donnot want to provide too many comparisons between the ncr and the
sim_hipd driver, even if I have actually done benchmarks that involve=20
the both drivers. What I can say is that I know all the pathes (C code and
SCRIPTS) of the both drivers and all my testing just met my expectations.
One of the great difference between the drivers is the Tps. I have posted
a bit about, but it seems people are too much selective on this list, even
if its traffic seem low.=20
I invite you to read my previous postings about this topic and will just=20
post the following output from iostat I got using 2 10K disk on a single=20
SYM53C896 channel (I have described the test conditions in a previous
posting):
(Cheetah2 LVD + DRVS LVD)
tty da0 da1 da2 cpu
tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id
1 20 4.00 3934 15.37 4.00 4098 16.01 0.00 0 0.00 2 0 24 7 =
68
0 0 4.00 4444 17.36 4.00 4466 17.44 0.00 0 0.00 4 0 53 14 =
29
0 0 4.00 4449 17.38 4.00 4460 17.42 0.00 0 0.00 4 0 53 15 =
28
0 0 4.00 4461 17.43 4.00 4460 17.42 0.00 0 0.00 3 0 56 14 =
27
0 0 4.00 4461 17.42 4.00 4462 17.43 0.00 0 0.00 3 0 52 16 =
29
0 0 4.00 4464 17.44 4.00 4466 17.45 0.00 0 0.00 3 0 54 17 =
25
0 0 4.00 4433 17.32 4.00 4466 17.45 0.00 0 0.00 4 0 52 17 =
27
0 0 4.00 4454 17.40 4.00 4465 17.44 0.00 0 0.00 2 0 54 15 =
28
0 44 4.00 3592 14.03 4.00 3485 13.62 0.00 0 0.00 4 0 39 14 =
43
0 0 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0100
The sym_hipd driver is also very fast using 53C875 and 895 controllers. I
cannot perform CCD testings at the moment since I donnot have time enough
for that, but I have some additionnal benchmarks I could flood the list
with.=20
If you want results, I will try to collect some next weekend and post
them.
On the result above (sequential read), may-be disconnections are not so=20
frequent, but I know the reselection path of the sym_hipd driver enough=20
to claim that this path is also very fast and certainly faster than the
ncr since it is just O(1) for both SCRIPTS and C code with regards to=20
the number of concurrent IOs (all that from 810A to C1010).
By the way, the above result requires the command overhead (without data)=
=20
to be as low as 62 micro-seconds and the ncr driver seems unable to
provide a command overhead lower that _twice_ this value.=20
G=E9rard.
On Mon, 27 Sep 1999, Kenneth D. Merry wrote:
> [ reply moved to the bottom, where replies belong ]
>=20
> Gerard Roudier wrote...
> > On 27 Sep 1999, Kevin Street wrote:
> > > Gerard Roudier <groudier@club-internet.fr> writes:
> > >=20
> > > > 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.=20
> > >=20
> > > > Latest revision:
> > > > sym-0.3.0-1990925
> > >=20
> > > 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=
=20
> > > performance to the ncr driver on make buildworld's (src on scsi, obj =
on ide). =20
> > >=20
> > > It's about 30% slower than the ncr driver with dump however. =20
> > > I was dumping from file systems on da1 to files on da0
> > > (a syquest syjet removable scsi).
> > >=20
> > > The sym driver gave me about 1125 - 1250 KBytes per second throughput=
=2E
> > > The ncr driver gave about 1550 - 1725 KBytes per second as reported b=
y=20
> > > dump. I tried these dumps a couple of times each with similar
> > > numbers. These are medium size (400M - 750M) dumps. Small file syst=
ems=20
> > > (eg root) were closer in speed with a slight edge to the ncr.
>=20
> [ ... ]
>=20
> > You test is not serious. If you only can provide 1.5MB/second throughpu=
t
> > 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.=20
>=20
> 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.
>=20
> In any case, the issue with dump isn't necessarily the throughput, but
> rather the number of transactions. dump is notoriously slow, for a varie=
ty
> of reasons. It tends to involve a high number of seeks. Here's an examp=
le
> from the first stage of a dump off of a ccd array consisting of 2 18G
> Seagate Cheetah II's:
>=20
> 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=20
> KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s=20
> 8.00 996 7.78 0.00 0 0.00 8.00 483 3.77 8.00 513 4.01=20
> 8.00 996 7.78 0.00 0 0.00 8.00 483 3.78 8.00 513 4.01=20
> 8.00 994 7.77 0.00 0 0.00 8.00 479 3.74 8.00 515 4.02=20
> 8.00 988 7.72 0.00 0 0.00 8.00 479 3.74 8.00 509 3.98=20
> =20
> Now that's a fair number of transactions per second, and certainly not a
> bad benchmark of drive and controller performance.
>=20
> Later stages of the dump don't go as fast, since they don't necessarily d=
o
> everything in 8K chunks. Here is sample iostat output from stage 4 of th=
e
> same dump on the same system:
>=20
> 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
>=20
> 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/s=
ec
> together. But the number of transactions is still fairly high.
>=20
> 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 happe=
n
> in each stage of the dump with each driver. That might shed light on
> whether there are any significant performance differences between the
> drivers.
>=20
> Ken
> --=20
> Kenneth Merry
> ken@kdm.org
>=20
>=20
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-scsi" in the body of the message
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?Pine.LNX.3.95.990928000341.351A-100000>