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