🚀 go-pugleaf

Hi. I have a disk transfer rate question for all you Mac II experts out
there. I wrote a MPW 2.0.2 tool called "disktime," in C, which allocates
a linked list of buffers and then writes those buffers to disk using
"write" (i.e., unbuffered I/O), keeping track of how long the writing
takes. I ran this program on a Mac II with a Jasmine ID 90, with system 
version 6.0.2 and finder 6.1.

The program takes two arguments: the number of 512-byte buffers to 
create and write, and the name of the file to write to. The only part 
of the program that gets timed is the loop that goes through the linked
list and writes buffers to disk.

Here are some of disktime's initial results:

	Time for 64 512-byte blocks:  0.13 secs. = 240.00 Kb/sec	
	Time for 128 512-byte blocks:  0.28 secs. = 225.88 Kb/sec
	Time for 256 512-byte blocks:  0.63 secs. = 202.11 Kb/sec
	Time for 512 512-byte blocks:  9.78 secs. = 26.17 Kb/sec

I then ran the Symantec Utilities' HDTuneup, which unfragmented the
disk. Here are some examples I then got from disktime:

	Time for 64 512-byte blocks:  0.08 secs. = 384.00 Kb/sec
	Time for 128 512-byte blocks:  0.18 secs. = 349.09 Kb/sec
	Time for 256 512-byte blocks:  0.37 secs. = 349.09 Kb/sec
	Time for 512 512-byte blocks:  9.08 secs. = 28.18 Kb/sec

I can tell myself a believable story about unfragmented files to
explain the improvement in the second set of numbers. Can anybody
explain the order of magnitude change in the transfer rate after 
the number of buffers surpasses some number between 256 and 512?
At first I surmised the disk controller might have a RAM buffer of 
its own, so things would slow down when the buffer got filled.
But if that's the case, I wouldn't expect to see any improvement
in the 64-128-256 buffer tests after unfragmenting the disk. I don't
understand this.


				Thanks,
				Ed Darken
				erd@cs.duke.edu