Date: Sat, 22 Apr 2000 16:17:26 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Kent Stewart <kstewart@3-cities.com> Cc: Michael Bacarella <mbac@nyct.net>, Alfred Perlstein <bright@wintelcom.net>, Kevin Day <toasty@dragondata.com>, hackers@FreeBSD.ORG Subject: Re: Double buffered cp(1) Message-ID: <200004222317.QAA56834@apollo.backplane.com> References: <Pine.BSF.4.21.0004221320250.38433-100000@bsd1.nyct.net> <200004221736.KAA55484@apollo.backplane.com> <3901F277.66DDDDAF@3-cities.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:I made some tests on my FreeBSD machine. In the past, double buffering
:only helps if you have concurrent I/O capability. You only have that
:if you have dual access to each I/O device (HD) via different data
:channels. We don't have that capability on PC's. The typical drives
:that we purchase have only one data path, i.e., the ribbon cable.
This is true for IDE. This is not true for SCSI. While it is true
that the ops have to run over the same physical cable, SCSI
supports (and our device drivers use) disconnection and multiple-command
queueing. This means that both reads and writes can be queued to the
drive during the period where the drive is seeking or searching.
Since command and data processing is asynchronous for all writes
and read lookaheads, you generally get the benefit of concurrent
I/O over a SCSI bus. This also means that adding multiple drives
to a single SCSI bus tends to multiply the performance where as
doing the same thing on an IDE bus results in little improvement.
:I tested build worlds where I created my /usr/obj on one controller
:and left the /usr/src on a different controller. The buildworlds are
:pretty much I/O bound. They ran faster but not that much faster when
Buildworlds are NOT I/O bound. They are *CPU* bound. This becomes
glaringly obvious when you mount /usr/src and /usr/obj over NFS
and look at the network traffic.
:is cached. The tests showed the scsi system was slower than the
:UDMA-33 drives in everything except for randon I/O and then it was
:much faster. It could mean that the buffering logic on the scsi HD and
:scsi controller were smart enough that everything was in cache.
This is a degenerate test case. SCSI systems have slightly higher
command processing overhead. Also, most IDE drives lie about
write-completion (they return a success status before actually writing
the data to the disk). This means that in tests where you are not
stressing the disk subsystem (and a buildworld does NOT stress the
disk subsystem!), IDE may appear to win out.
-Matt
:Kent
:
:--
:Kent Stewart
:Richland, WA
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004222317.QAA56834>