Date: Sat, 13 Feb 1999 13:34:03 -0700 (MST) From: "Kenneth D. Merry" <ken@plutotech.com> To: julian@whistle.com (Julian Elischer) Cc: andre.albsmeier@mchp.siemens.de, freebsd-scsi@FreeBSD.ORG Subject: Re: Is CAM slower than the old SCSI layer for JAZ drives? Message-ID: <199902132034.NAA45976@panzer.plutotech.com> In-Reply-To: <Pine.BSF.4.05.9902130013070.310-100000@s204m82.isp.whistle.com> from Julian Elischer at "Feb 13, 1999 0:16: 8 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote...
>
> On Fri, 12 Feb 1999, Kenneth D. Merry wrote:
>
> > Andre Albsmeier wrote...
> > > I have made an odd observation. Copying a large file from
> > > my 100MBit net to a 2GB jaz, I noticed that 3.1-BETA took
> > > a lot more time than it used to under 2.2.8-STABLE.
> > > Exact (well, as exact as dd can be) measurements told me:
> > >
> > > 3.1-BETA:
> > > 135447409 bytes transferred in 178.638903 secs (758219 bytes/sec)
> > >
> > > 2.2.8-STABLE:
> > > 135447409 bytes transferred in 87.649259 secs (1545334 bytes/sec)
> > >
> > > This is nearly exact twice the time for 3.1 than for 2.2.8.
> > > The network is okay, a dd to /dev/null gives me:
> > > 135447409 bytes transferred in 13.553990 secs (9993176 bytes/sec)
>
> I've heard from several sources (notibly Simon Shapiro)
> that something in the CAM code is slowing things down.
> However I don't think it's likely to be a theoretical thing,
> but possibly an implimentation gothca.. in THEORY CAM should
> equal or surpass the old system, with many organisational advantages.
I think Justin has said before (not sure whether Simon has confirmed this)
that the problem is the bufq_disksort() call in the da driver. The old
sd driver did things like this:
#ifdef SDDISKSORT
bufq_disksort(&sd->buf_queue, bp);
#else
bufq_insert_tail(&sd->buf_queue, bp);
#endif
Since SDDISKSORT wasn't defined (that I can tell), buffers were always
inserted at the tail.
The CAM da driver always uses bufqdisksort(), which supposedly is the thing
that is slowing things down somewhat.
An easy way to see for sure is to replace the bufqdisksort() call in
scsi_da.c with bufq_insert_tail().
Ken
--
Kenneth Merry
ken@plutotech.com
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?199902132034.NAA45976>