Date: Mon, 20 Feb 1995 04:03:25 -0500 (EST) From: Peter Dufault <dufault@hda.com> To: toor@jsdinc.root.com (John S. Dyson) 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 Subject: Re: cvs commit: src/sys/sys buf.h Message-ID: <199502200903.EAA06837@hda.com> In-Reply-To: <199502200058.TAA00246@jsdinc> from "John S. Dyson" at Feb 19, 95 07:58:15 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199502200903.EAA06837>