Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 27 Nov 1998 16:42:22 +1030
From:      Greg Lehey <grog@lemis.com>
To:        Stormy Henderson <stormy@futuresouth.com>, questions@FreeBSD.ORG
Subject:   Re: Slow CCD
Message-ID:  <19981127164222.S682@freebie.lemis.com>
In-Reply-To: <199811270320.VAA23941@shell.futuresouth.com>; from Stormy Henderson on Thu, Nov 26, 1998 at 09:20:35PM -0600
References:  <199811270320.VAA23941@shell.futuresouth.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, 26 November 1998 at 21:20:35 -0600, Stormy Henderson wrote:
> I have an Adaptec 2940 with 2 matched 1GB SCSI-2 drives, 5400rpm, 10ms access.
> Using dd bs=1m count=128 if=/dev/da0s1e of=/dev/null, I get 4MB per second,
> and about the same with 8k blocks.

Sure, you're using the block device interface.  It will largely ignore
your block size when performing reads.  Try /dev/rda0s1e.

> Using CCD with an interleave of 512, and the same dd, I get 1MB per
> second.

You don't say whether you're using the raw or the block device.
Perform all tests with the raw device.

Do you mean an interleave spec of 512, or 512 byte interleave
(i.e. interleave spec 1)?  That would be tiny.

> Increasing the interleave to 65535 improves performance to a
> miserable 1.7MB per second.

You should see almost no difference between 512 block (256 kB) and
65535 block (32 MB) interleaves.

> Forgetting interleave and just concatting them doesn't do any
> better.
>
> I have a p133, by the way.

That won't have much to do with it.

> Is the abysmal performance normal on my hardware?  I'm using
> 3.0-19981123-SNAP.

We don't really know what your hardware is.  The fact that the drives
have a 10 ms positioning time doesn't say very much about them, beyond
the fact that they're not bleeding edge technology.

I tried out some of these things, and found:

# dd if=/dev/sd1h of=/dev/null bs=1m count=4
4+0 records in
4+0 records out
4194304 bytes transferred in 35.344403 secs (118670 bytes/sec)

Now these are slow drives, but they're not that slow.  I think we
might have a problem somewhere--read on.  Doing it with raw I/O, I
got:

# dd if=/dev/rsd1h of=/dev/null bs=1m count=4
4+0 records in
4+0 records out
4194304 bytes transferred in 3.598270 secs (1165645 bytes/sec)

This is probably about the true speed of my ancient CDC drives.

I don't have ccd running, but I tried it with vinum:

# dd if=/dev/vinum/rsrc of=/dev/null bs=1m count=4
4+0 records in
4+0 records out
4194304 bytes transferred in 3.815559 secs (1099263 bytes/sec)

# dd if=/dev/vinum/rsrc of=/dev/null bs=64k count=64
64+0 records in
64+0 records out
4194304 bytes transferred in 3.727528 secs (1125224 bytes/sec)

As you can see, the smaller block size was marginally faster.  This is
probably because of the additional overhead that vinum has when the
block size is greater than 128 kB; the current version of Vinum is
full of slowing-down debug code.  I'd expect the performance to be
pretty much the same as with the raw disk without the debug code.
Interestingly, reading a Vinum block device is significantly faster
than reading the underlying block device:

# dd if=/dev/vinum/src of=/dev/null bs=64k count=64
64+0 records in
64+0 records out
4194304 bytes transferred in 9.791926 secs (428343 bytes/sec)
# dd if=/dev/sd1h of=/dev/null bs=64k count=64
64+0 records in
64+0 records out
4194304 bytes transferred in 36.563592 secs (114713 bytes/sec)

I can't find any explanation for this.  This is 3.0-CURRENT, and I
suspect we have a problem somewhere in the block device subsystem.

Greg
--
See complete headers for address, home page and phone numbers
finger grog@lemis.com for PGP public key

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



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