ed@sfucmpt (Ed Bryant) (11/25/83)
And now, more in the m and n saga:
We have a VAX 750, 4Mb memory, and a couple of ra81's on a uda50 controller,
running Unix 4.1b. Since it wasn't doing anything for a couple of days,
I ran the following script:
#!/bin/csh
echo "test of disk m and n factors"
date
foreach x (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17)
foreach y (100 256 300 327 357 364 512 714 728 1024)
echo "m n: $x $y"
fsck -s$y\:$x /dev/ra1g >/dev/null
mount /dev/ra1g /mnt
echo -n " Writing: "
time sh -c "dd if=/usr/bigfile of=/mnt/test bs=10240 >/dev/null 2>&1"
echo -n " Reading: "
time sh -c "dd if=/mnt/test of=/dev/null bs=10240 >/dev/null 2>&1"
echo -n " Reading: "
time sh -c "dd if=/mnt/test of=/dev/null bs=10240 >/dev/null 2>&1"
rm -f /mnt/test
umount /dev/ra1g
end
end
echo "test complete"
date
According to the ra81 manual the n should be 364 calculated as follows:
7 surfaces @ 2 heads per surface @ 52 512 byte sectors per track =
728 sectors per cylinder, or 364 file blocks per cylinder.
The results I obtained are:
---------------------------------------------------------------------------
Results of disk tests on a Vax-11/750, ra81, with uda50 controller
m = disk sector skip factor, n = file blocks per cylinder
Average read time (in seconds, 2 tries) of a 10 Mbyte file
m\n | 100 | 256 | 300 | 327 | 357 | 364 | 512 | 714 | 728 | 1024 |
----------------------------------------------------------------------------
1 | 168 168 168 167 167 167 168 168 168 168 |
2 | 169 170 169 169 170 170 170 170 170 170 |
3 | 171 171 172 171 171 171 171 171 171 171 |
4 | 116 115 115 114 115 115 115 114 115 115 |
5 | 113 112 111 112 112 111 111 111 111 111 |
6 | 118 117 117 117 118 116 115 116 117 115 |
7 | 110 108 106 107 109 107 107 106 107 107 |
8 | 89 87 88 88 89 88 88 87 89 87 |
9 | 84 83 84 83 83 84 83 83 83 84 |
10 | 92 90 88 87 86 87 87 87 87 87 |
11 | 96 95 96 94 94 96 96 96 96 96 |
12 | 104 102 102 103 101 104 104 104 103 104 |
13 | 111 110 110 113 109 111 111 111 111 111 |
14 | 118 117 117 120 117 119 119 119 120 119 |
15 | 126 126 125 128 124 127 127 126 127 127 |
16 | 134 134 133 135 132 134 135 134 134 135 |
17 | 141 141 140 143 141 142 142 142 142 142 |
----------------------------------------------------------------------------
the read time is the elapsed time, since the system time and user time
are the same in each case. The theory is, I believe, that system time does
not include waiting for the disk.
These results are puzzling, since it appears that the choice of n is
irrelevant, but the choice of m is. This appears to be a contradiction
to the Unix manual! Perhaps the uda50 is smarter than average?
These results are fairly accurate, I think, since there are no terminals
connected to the VAX, and no other system activity.
If and when 4.2 arrives, I propose to run these tests again,
and if the results are any different, I will post them.
Ed Bryant
Laboratory for Computer and Communications Research
Simon Fraser University
(604-291-4430)
... ubc-vision!sfucmpt!edwls@astrovax.UUCP (11/30/83)
One would expect that the elapsed time would be sensitive to "m" but insensitive
to "n". "m" is the interlace factor, the spacing of the blocks on the disk,
which sets how much time there is before the the system must be ready to access
the next block. Otherwise the system has to wait for the disk to go all the way
around and catch it on the next revolution.
The "n" value, in contrast, is provided only to keep the interlacing within
a cylinder, so that no head movement has to take place until that cylinder is
finished. If "n" is wrong then the interlacing straddles cylinder boundaries
and extra head movement does take place. However, for reasonable values of
"m" and "n" the extra number of disk accesses which involve head movement is
still small compared to the number of accesses which do not, and the effect on
the elapsed time is only minor.
By the way, I hope someone at Berkeley is saving this m and n info to include
in future manuals.
--
Bill Sebok Princeton University, Astrophysics
{allegra,akgua,burl,cbosgd,decvax,ihnp4,kpno,princeton}!astrovax!wls