Path: utzoo!yunexus!ists!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!uakari.primate.wisc.edu!ames!sun-barr!lll-winken!lll-crg.llnl.gov!casey
From: casey@lll-crg.llnl.gov (Casey Leedom)
Newsgroups: comp.arch
Subject: Re: Slow SCSI
Keywords: Peripheral Controllers, Gather, Scatter, I/O Architecture
Message-ID: <38912@lll-winken.LLNL.GOV>
Date: 19 Nov 89 04:10:27 GMT
Article-I.D.: lll-wink.38912
References: <18292@watdragon.waterloo.edu> <35985@ames.arc.nasa.gov>
Sender: usenet@lll-winken.LLNL.GOV
Reply-To: casey@lll-crg.llnl.gov (Casey Leedom)
Organization: Lawrence Livermore National Laboratory
Lines: 70


  Ack.  This is probably a mistake since it's just this far away from a
flame, but sometimes you just have to do what you have to do ...

| From: ccplumb@rose.waterloo.edu (Colin Plumb)
| 
| One common reason [that disk transfer is so slow] is that the file
| systems are bloody awful.  The BSD "Fast File System" will get, on a good
| day, 25% of the available disk bandwidth.  A lot of it is just
| fragmentation, doing reads a block at a time (so you have to turn around
| the SCSI bus and issue a new command to get the next 8K, during which
| time, you might just miss the next sector), and copying in the buffer
| cache.  Copying large expanses of bytes around is just stupid if it can
| be avoided.
| 
| Did you have a look at the system time for copying a 1 meg file to
| /dev/null?  On the 4.3 BSD microvax I'm on, it's 0.7 seconds.  (5 seconds
| real, but the load average is 2.7 and I shouldn't be reading news.)  Why
| on earth does it take 700,000 instructions to find 256 4K blocks?  I
| assume "cp" and /dev/null aren't doing anything grotesquely stupid, but I
| may be wrong... anyway, *something* takes far too long.

  Please read ``A Fast File System for UNIX'', McKusick, Joy, Leffler,
and Fabry, Computer Systems Research Group, Computer Science Division,
Department of Electrical Engineering and Computer Science, University of
California, Berkeley.

  You're just so wrong I don't even want to start on addressing this
other than to point it out so that people won't think that it's true.

	1. Study the problem.
	2. Make hypothesis.
	3. Design test of hypothesis.
	4. Perform test.
	5. Analyze test results.
	6. Go to 1.

I.e. the ``scientific method'' (I've probably mistated the exact outline
of the "scientific method" as described in many high school science
texts.  Sorry.)

  Two points in particular should be addressed however:

    1.	Your test of .7 seconds of system time is far too short.  Since
	CPU time is attributed to various states of the system by sampling
	the state at discrete intervals, that means you have a digital
	data set.  Your sample set is way too small.  Moreover, you have
	to be extremely careful when testing to make sure you're only
	measuring what you want to measure and not program load time and
	other factors that may crop up.  I.e. the shell ``time'' command
	is not going to work in most cases.

    2.	The Fast File System was tuned for ``typical'' UNIX work loads.
	What's typical for UNIX has changed over the years with people
	using it for scientific computing, business, etc.  Two areas where
	the Fast File System does fall down are in the areas of non-
	sequential file access (note - I did *NOT* say random) and large
	file support.  These are areas if current research.  (There will be
	a couple of papers presented at this Winter's USENIX on these
	topics.)

	There are undoubtedly other types of access which are not handled
	optimally by the Fast File System, but we have to design to what
	we know the systems are going to be used for and provide for
	other activities if we can by appropriate generalization and
	flexibility.

  Sorry for the flame-like nature of this posting.

Casey