From owner-freebsd-hackers Fri Sep 1 20:39:51 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id UAA20774 for hackers-outgoing; Fri, 1 Sep 1995 20:39:51 -0700 Received: from cs.sunysb.edu (sbcs.sunysb.edu [130.245.1.15]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id UAA20762 for ; Fri, 1 Sep 1995 20:39:48 -0700 Received: from sbgrad9.csdept (sbgrad9.cs.sunysb.edu [130.245.2.29]) by cs.sunysb.edu (8.6.12/8.6.9) with SMTP id XAA24086; Fri, 1 Sep 1995 23:38:51 -0400 Date: Fri, 1 Sep 1995 23:38:51 -0400 From: Michael Vernick Message-Id: <199509020338.XAA24086@cs.sunysb.edu> Received: by sbgrad9.csdept (4.1/SMI-4.1) id AA13252; Fri, 1 Sep 95 23:37:21 EDT To: rgrimes@gndrsh.aac.dev.com, freebsd-hackers@FreeBSD.org In-Reply-To: "Rodney W. Grimes"'s message of Thu, 31 Aug 1995 13:10:34 -0700 (PDT) <199508312010.NAA12388@gndrsh.aac.dev.com> Subject: 4GB Drives Sender: hackers-owner@FreeBSD.org Precedence: bulk >You see, in modern workstation disk drives you have something called >spindle sync. Well, when you set up spindle sync you have 2 modeselect >values you tweak. One bit says who is the sync master and who are >the sync slaves. Then for each slave drive you tweak another value >that is used to offset the spindles from perfect sync so that the I/O >of block zero of a track on drive 0 of a stripe set has just finished >the scsi bus transfer when block zero of a track on drive 1 is about to >come under the heads. Why do you want the data under the heads when the SCSI bus becomes free? Wouldn't you rather have the data already in the disk cache? If the bus is free and the disk is transferring from the medium and out over the bus, the bottleneck is the disk transfer rate. However if the data had already been in the cache it can go at SCSI bus speeds. As for the 85% bandwidth over the SCSI you have achieved, that is the maximum that I can get. Rather than worry about seeks and latency delays I simply request the same data over and over from the disks. I bypass the file system code and make sure each request (64K, or 128 sectors) goes back to the disk. However, the data is already in the disk cache thus incurring no seeks, nor rotation delays. With 3,4 and 5 disks on a single controller it maxes out at 8.5MBsec. Thus, the controller, disk and bus overhead must account for the other 15%. If you can get rid of that overhead, let me know. :) mv