From owner-cvs-sys  Mon Feb 20 01:05:35 1995
Return-Path: cvs-sys-owner
Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id BAA02061 for cvs-sys-outgoing; Mon, 20 Feb 1995 01:05:35 -0800
Received: from hda.com (hda.com [199.232.40.182]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id BAA02052; Mon, 20 Feb 1995 01:05:21 -0800
Received: (dufault@localhost) by hda.com (8.6.9/8.3) id EAA06837; Mon, 20 Feb 1995 04:03:26 -0500
From: Peter Dufault <dufault@hda.com>
Message-Id: <199502200903.EAA06837@hda.com>
Subject: Re: cvs commit: src/sys/sys buf.h
To: toor@jsdinc.root.com (John S. Dyson)
Date: Mon, 20 Feb 1995 04:03:25 -0500 (EST)
Cc: zeta.org.au!bde@implode.root.com,
        estienne.cs.berkeley.edu!gibbs@implode.root.com, toor@Root.COM,
        CVS-commiters@freefall.cdrom.com, bde@zeta.org.au,
        bde@freefall.cdrom.com, cvs-sys@freefall.cdrom.com,
        zeta.org.au!toor@implode.root.com
In-Reply-To: <199502200058.TAA00246@jsdinc> from "John S. Dyson" at Feb 19, 95 07:58:15 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Content-Length: 1903      
Sender: cvs-sys-owner@freebsd.org
Precedence: bulk

John S. Dyson writes:
> 
> > 
> > I think one IDE PIO speed is 3.3M/sec so the time per word is 0.67usec.
> > The new EIDE PIO speed of 11M/sec will reduce the problem in a while
> > for a while.  I don't see how reducing the I/O size makes any difference
> > if the disk+controller can transfer faster than the bus.  Won't the
> > driver just loop over more buffers?  There may be short pauses in I/O
> > while the drive+controller prepares the next I/O, but only if drive+
> > controller didn't do enough read ahead.
> > 
> I definitely was not suggesting that the current situtation is any better
> than the buffer chaining proposal.  Quite the contrary...  But, the point
> that I have been trying to make is that we can easily make the problem
> worse.
> 
> The I/O requests can be structured so that a context switch is required
> to queue a new buffer.  The throughput of the system would definitely
> be less, but we could improve real-time scheduling performance.  I do
> believe that in "normal" systems, we do want to cluster and make the
> controller busier.  But in real-time situations it can be counter-productive.
> 
> Perhaps, for 2.2+ we could consider re-vamping the kernel for real-time
> (or closer to real-time) performance???  Please note, these are somewhat
> random thoughts, and right now I have no agenda,  just trying to give
> feedback...

Since determinism is more important than performance, there are
situations where 100ms worse case process resumption is useful and
5ms "usual and customary" is useless.  So a useful way to proceed
is:

Make the I/O configurable (largest transfer, number of entries on the
proposed buffer chain);

Instrument the system so the actual I/O performance is measurable.

-- 
Peter Dufault               Real Time Machine Control and Simulation
HD Associates, Inc.         Voice: 508 433 6936
dufault@hda.com             Fax:   508 433 5267