Skip site navigation (1)Skip section navigation (2)
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>