Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site hsi.UUCP
Path: utzoo!linus!decvax!microsoft!uw-beaver!cornell!vax135!ariel!hou5f!hou5g!hou5h!eagle!harpo!seismo!hao!kpno!hsi!stevens
From: stevens@hsi.UUCP
Newsgroups: net.unix-wizards
Subject: m & n values for disks
Message-ID: <126@hsi.UUCP>
Date: Fri, 2-Dec-83 08:49:45 EST
Article-I.D.: hsi.126
Posted: Fri Dec  2 08:49:45 1983
Date-Received: Sun, 4-Dec-83 07:39:27 EST
Organization: Health Systems Intl.  New Haven,CT
Lines: 75


     Regarding all the notes recently concerning the m&n values for
mkfs on the new disks (RA80 and RA81), the original work on this
topic was done in 1979 by Walt Lazear and Charles Muir at the Air Force
Data Services Center and presented at the January 80 Usenix conference
in Boulder.  Their work was done under Version 6 but the approach is
still valid and consists of:

   - Measure the CPU speed in blocks/sec (512-byte blocks are used
     throughout).  To do this execute the program

	main()
	{
		char buff[512];	/* 1024 under BSD */

		while (read(0, buff, 512 or 1024) > 0)
			;
	}

     using some large file as input (more than 2Mb).  Calculate the
     system's blocks/sec (BPS) by dividing the file size in 512-byte blocks
     by the SYSTEM time to read.  (Make sure the file does not have
     "holes" in it - that all the bytes are really there.)
     Note that the interleave factor used to measure this makes no difference
     as you are using the system time, not the clock time.

   - Calculate the number of blocks/sec that the disk generates.
     This is the number of 512-byte blocks per track.  I think you'd
     better use all the blocks on the track, even if some are not
     used by the software (alternate sector handling by the controller);
     for example, use 52 for the RA81, not 51.

   - Calculate the next integer greater than
		disk BPS / CPU BPS
     and you have the interleave factor, m.
     As Ed Bryant at Simon Fraser found out by tests, the m value is
     much more important than the n value.

Some values that I have measured and some values that appeared in the
original paper for system speeds are:

	System	BPS	Unix version
	------  ---	------------
	IBM PC	113	Venix/86, XT disk, I measured
	11/34	119	Version 6, from paper
	11/70	210	Version 6, from paper
	11/70	190	Version 7, I measured
	11/750	385	4.1 BSD, without FPA, I measured
	11/750	410	4.1 BSD, with FPA, I measured

For the RA81 on a 750 without the FPA, m = 3120 / 52 = 9, which is
just what Ed Bryant measured and I got the same value in some
identical tests.  (3120 = 60 revs/sec * 52 blocks/track.)
Similarly, for an RL02 on a 750 without the FPA, m = 800 / 385 = 3,
which is what I measured on an actual RL02.

The difference in Unix versions on the 11/70 numbers above are due
to the additional overhead in V7 from V6.  The difference in the two
11/750 values must be due to the speed increase in the integer multiply
and divide when the FPA is present, since I don't think the kernel uses
floating point anywhere in the block i/o system or in any of the disk
drivers.

In summary, the 4.1 BSD mkfs manual page that says to use m=3 all the time
is wrong.  Calculate your own values ! (But you don't need to run
all the timing tests - use the formula above.)
I'd be very interested if anyone with a 730 or 780 running 4.1 BSD could
calculate and post the system speeds (BPS) with and without the FPA.

	Richard Stevens
	Health Systems International, New Haven, CT
	{ decvax | hao | seismo | sdcsvax } ! kpno ! hsi ! stevens
                                             ihnp4 ! hsi ! stevens

p.s. - I believe all of this is irrelevant under 4.2 BSD.