From owner-cvs-sys  Sun Feb 19 18:04:54 1995
Return-Path: cvs-sys-owner
Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id SAA23521 for cvs-sys-outgoing; Sun, 19 Feb 1995 18:04:54 -0800
Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id SAB23500; Sun, 19 Feb 1995 18:04:46 -0800
Received: from jsdinc.root.com (uucp@localhost) by Root.COM (8.6.8/8.6.5) with UUCP id NAA00775; Sun, 19 Feb 1995 13:10:48 -0800
Received: (root@localhost) by jsdinc (8.6.9/8.6.5) id PAA01558; Sun, 19 Feb 1995 15:52:13 -0500
From: "John S. Dyson" <toor@jsdinc.root.com>
Message-Id: <199502192052.PAA01558@jsdinc>
Subject: Re: cvs commit: src/sys/sys buf.h
To: estienne.cs.berkeley.edu!gibbs@implode.root.com (Justin T. Gibbs)
Date: Sun, 19 Feb 1995 15:52:13 -0500 (EST)
Cc: toor@Root.COM, bde@zeta.org.au, bde@freefall.cdrom.com,
        CVS-commiters@freefall.cdrom.com, cvs-sys@freefall.cdrom.com
In-Reply-To: <199502191918.LAA06025@estienne.cs.berkeley.edu> from "Justin T. Gibbs" at Feb 19, 95 11:18:17 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 1334      
Sender: cvs-sys-owner@freebsd.org
Precedence: bulk

> 
> Without looking at increasing the max I/O size, will there be a perfomance
> gain in this approach?  If so, it becomes cheep and easy to change the 
> max I/O size based on benchmarks and individual needs.  Will say doubling
> the max to 128k further compromise real time performance?  What percentage
> of I/O transactions will even approach this size?
> 
> -- 
> Justin T. Gibbs
> ==============================================
> TCS Instructional Group - Programmer/Analyst 1
>   Cory | Po | Danube | Volga | Parker | Torus
> ==============================================
> 

This is my worry, not that I *actually* know the following to be TRUE:

Well, it appears that on an IDE drive there is the >possibility< for it to
stream data for a pretty long while.  It would cause the system to be I/O
(interrupt) bound (because of the slow ISA bus) for a long time.  There is the
possibility for this I/O operation to last approx 64K * ??usecs/transfer :-(.
(Bruce knows more about ISA bus timing than I do, but I guess that it is about
.5usecs??? per word or more).  That is a long, long time.  The kernel cannot
do much about it once the (long) I/O operation is queued. 

Bus mastering SCSI worries me much less, but still is a concern (as drives
get faster and the old ISA-bus stays the same speed) :-).

John
dyson@root.com