Tuning for performance or reliability

[R. David Whitlock]

I had intended to write a long-ish reply to this, but just haven't gotten
the cycles today, and you seem to have found what you needed.  However,
I'd like to also point out that the Kernel Traffic page reports on a lot
of these kinds of benchmarks, and will likely have even more tests along
these lines you can use.  These come up quite often and I seem to recall
there was a very similar thread on this in one of the last 2 or 3
editions.  Benchmarking is of particular intrest to these guys, and they
like to generate hard data...  (particularly in light of the recent Linus
"oops")

Kernel Notes is a summary of the weekly traffic on the linux
kernel developers list, and can be found here:

http://kt.zork.net/kernel-traffic/latest.html

Hope this is helpful to others as well...

(BTW, anyone else out there on the list have some _informed_ opinions on
some of the recent happenings with the VM?)

-D
	"What you hear isn't necessarily what was said,
 	what you read isn't necessarily what was written."
			-Dostoevsky

On Thu, 18 Oct 2001, Jeff Silverman wrote:

> Jeff Silverman wrote:
>
> > ...
> > here might I find generally accepted
> > benchmark software so I can measure Kernel and NFS efficientcy?
> > ...
>
> The Linux NFS howto, Chapter 5,
> http://www.linuxdoc.org/HOWTO/NFS-HOWTO/performance.html#NFSD-INSTANCE, has an
> answer:
>
> Step 1:
>
>
>  So we'll want to experiment and find an rsize and wsize that works and is as
> fast as possible. You can test the speed of your options with some simple
> commands.
>
>  The first of these commands transfers 16384 blocks of 16k each from the special
> file /dev/zero (which if you read it just spits out zeros _really_ fast) to the
> mounted partition. We will time it to see how long it takes. So, from the client
> machine, type:
>
>     # time dd if=/dev/zero of=/mnt/home/testfile bs=16k count=16384
>
>
>  This creates a 256Mb file of zeroed bytes. In general, you should create a file
> that's at least twice as large as the system RAM on the server, but make sure
> you have enough disk space!
>
> Step 2:
>
> Then read back the file into the great black hole on the client machine
> (/dev/null) by typing the following:
>
>     # time dd if=/mnt/home/testfile of=/dev/null bs=16k
>
>
>  Repeat this a few times and average how long it takes. Be sure to unmount and
> remount the filesystem each time (both on the client and, if you are zealous,
> locally on the server as well), which should clear out any caches.
>
> --
> Jeff Silverman, sysadmin for the Research Computing Systems (RCS)
> University of Washington, School of Engineering, Electrical Engineering Dept.
> Box 352500, Seattle, WA, 98125-2500 FAX: (206) 221-5264 Phone (206) 221-5394
> jeffs at rcs.ee.washington.edu     http://rcs.ee.washington.edu/~jeffs
>
>
>
>