From owner-freebsd-hackers Sat Apr 22 16:17:38 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 0BECA37B89E for ; Sat, 22 Apr 2000 16:17:35 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA56834; Sat, 22 Apr 2000 16:17:26 -0700 (PDT) (envelope-from dillon) Date: Sat, 22 Apr 2000 16:17:26 -0700 (PDT) From: Matthew Dillon Message-Id: <200004222317.QAA56834@apollo.backplane.com> To: Kent Stewart Cc: Michael Bacarella , Alfred Perlstein , Kevin Day , hackers@FreeBSD.ORG Subject: Re: Double buffered cp(1) References: <200004221736.KAA55484@apollo.backplane.com> <3901F277.66DDDDAF@3-cities.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :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