optimal mkfs m,n for Rm80 and Eagle on Vax 750 4.1 BSD

[wls at astrovax.UUCP]

A short while back our Fujitsu eagle arrived.  In the ensuing mass confusion
while the file systems were moved around, a semiresident wizard here (Tsutomu
Shimomura, now astrovax!escher!tsutomu) ran some tests to determine optimal
m and n factors.  As previously mentioned the n factor to use is the number
of blocks (1024 bytes for 4.X bsd)  that will fit on a cylinder.  The best "m"
factor depends on the setup overhead involved and will depend on the speed of
your cpu and operating system.  We have a VAX 750 and run 4.1 BSD.
 The method he used to determine "m" involved (on a quiet system):

	mkfs .....

Make a file system on device to be tested with the desired "m" and "n" values

	mount ...
	cd  ...

mount file system and change directory to one on the file system.

	dd if=/dev/rhpXX of=bigfile bs=10k count=1000

create big file on the file system.  Here /dev/rhpXX is just a convenient
source of bytes.  Finally:

	time dd if=bigfile of=/dev/null bs=20k

and write time the time.  Try this for a range of "m" values and pick the
"m" which minimizes the time. 

 There will usually be a "break", as m is increased the amount of time taken
will dramatically become shorter at some "m" value, then as "m" is further
increased the time taken will gradually increase again.
  This method optimizes the behavior for short term bursts. Unfortunately
the behaviour on most busy system activity is closer to "worst-case" and
the value of "m" doesn't matter much.

The values he obtained are:

m=5	n=217	Rm80
m=9	n=480	Eagle SI controller
m=7	n=80	CDC BA5A1A (80 Mbyte Winchester) with Emulex controller running
		off unibus using sys/dev/up.c driver.

These "m" values are rather larger than expected (i.e. the system is rather
slower than expected).  The Vax 780 should (i.e. it better) have smaller "m"
values.
-- 
Bill Sebok	Princeton Univ. Astrophysics
{allegra,akgua,burl,cbosgd,decvax,ihnp4,knpo,princeton}!astrovax!wls