Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!murtoa.cs.mu.oz.au!munnari.oz.au!otc!metro!extro!natmlab!ditsyda!evans
From: evans@ditsyda.oz (Bruce Evans)
Newsgroups: comp.os.minix
Subject: Re: Disk performance under Minix
Message-ID: <2134@ditsyda.oz>
Date: 17 Aug 89 19:31:42 GMT
References: <21290@louie.udel.EDU> <18613@princeton.Princeton.EDU> <1599@psueea.UUCP>
Reply-To: evans@ditsyda.mq.oz (Bruce Evans)
Organization: CSIRO DIT Sydney, Australia
Lines: 59

In article <1599@psueea.UUCP> kirkenda@jove.cs.pdx.edu (Steve Kirkendall) writes:
>...
>I ran some speed tests on my ST, equipped witha Supra hard disk.  My tests all
>concerned reading, not writing.  The results of the test are presented below,
>...
>The test performs N calls to read(), giving a buffer size of (2meg / N).
>...
>[Good explanation of how to interpret the tests.]
>...
>I just added read-ahead to the device driver, and reran the test on /dev/hd2,
>with the following results:
>
>Blk Size  Test Time    Speed
>  512         68         30 kb/sec	(was 21 kb/sec)
> 1024         55         37 kb/sec	(was 24 kb/sec)
> 2048         43         48 kb/sec	(was 31 kb/sec)
> 8192         43         48 kb/sec	(was 35 kb/sec)
>16384         43         48 kb/sec	(was 37 kb/sec)
>
>So we get a 30%-50% improvement with read-ahead in the driver.  That's nice,
>but I expected more.  The modified driver always does physical reads of 4k
>or more, so I expected a speed just slightly less than what a 4096 byte block
>would get you on the raw disk -- about 90 kb/sec.

Fragmentation is the main obstacle. I tried full-track read-ahead. The hit
rate was dismal.

>We could probably do better with read-ahead implemented in the cache, since
>that way we could reduce the number of messages passed to/from the device
>driver, and also eliminate the chore of copying from the driver's buffer
>to FS's buffer.

My method is to always read-ahead up to 15 blocks (the size of a track on a
1.2M floppy).  FS guesses the track boundaries and rounds up read requests
to match. It also communicates with the block device drivers up to NR_BUFS
blocks at a time. FS sorts the block numbers in increasing order. All the
drivers except FLOPPY just loop over the blocks. But now the loop is local
to the driver and the precious time between blocks is not wasted talking to
FS and copying data between FS and users.

For a 20MHz 386 and a drive limited to 255 kb/sec, and a 320K cache:

Blk Size  Test Time    Speed
  512         15        137 kb/sec  (was 48 kb/sec)
 1024         14        146 kb/sec  (was 49 kb/sec)
 2048         13        158 kb/sec  (was 49 kb/sec)
 8192         11        186 kb/sec  (was 48 kb/sec)
16384         12        171 kb/sec  (was 48 kb/sec)

The extra CPU power makes the old FS (286 protected mode) give the same
times for all sizes. The large cache is not particularly important for a
sequential read like this.

It will be difficult to achieve such rates on slower machines. I found that
an AT kept up with 3:1 interleave only in its Turbo mode. 8088's will have
difficulty with even 20K/sec from a floppy. I only see how to do it using
extra blocking and unblocking code.
-- 
Bruce Evans		evans@ditsyda.oz.au