Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!batcomputer!munnari.oz.au!metro!natmlab.dap.csiro.au!ditsydh.syd.dit.CSIRO.AU!evans From: evans@syd.dit.CSIRO.AU (Bruce.Evans) Newsgroups: comp.os.minix Subject: Re: Questions for Bruce on 386 patches Keywords: 386 patches questions Bruce Evans Message-ID: <1990Sep25.133833.8269@syd.dit.CSIRO.AU> Date: 25 Sep 90 13:38:33 GMT References: <2141@bnlux0.bnl.gov> Organization: CSIRO Division of Info Tech, Sydney, Australia Lines: 46 In article <2141@bnlux0.bnl.gov> scottc@bnlux0.bnl.gov (david scott coburn) writes: >1) from which directory should the file 'makelib' be run? I created the > directory /usr/src/minix386 and unloaded the tar files into it (bcc, > bccbin16, bccbin32, and bcclib). When I cd to /usr/src/minix386/lib The file runtime.crc gives complete paths to show where everything goes. makelib should be run from its own directory (/usr/src/lib/bcc). The /usr/src/ part may be varied. >b) ... > rebuilding will be done from, or will there be still another set (lib, > fs, kernel...) within the /usr/src/minix386 directory? The minix386 directory is only for convenience of distribution. Put everything in the runtime places. >I transferred about 10,000 blocks of data between partitions using two >tars piped together. It took about 20 minutes to complete. So... > > 2 (read and write) x 10,000,000 bytes / 1200 seconds = ~170kb/sec > >Any comments on this through-put? I have a ZEOS 386sx 16MHz, 2M ram and >a Conner 80M IDE drive. 170K/sec would be great with 2:1 interleave, but you are only getting 17K/sec. I get about 70K/sec using gnu tar 1.08, 120K/sec using cp, and 200K/sec for input of /dev/hd0, out of a maximum of 250K/sec from a 2:1 controller on a 20MHz 386. The 120K/sec is (almost :-) acceptable but below that is not. The pipes in the tar copy seem to be expensive. The main reason that you are only getting 17K/sec is probably that you are using Minix tar. This does all i/o in the mismatched block size of 512 bytes. This causes pre-reads for writes (one more i/o operation so 17K/sec is actually 25K/sec) and defeats the read-ahead algorithm. Without read-ahead, almost all hard disks are limited to 60K/sec (1 block/rev). Another point is that tarring will access a lot of directory and inode blocks and thrash the cache more than a cp. (3 mounted partitions on my system consume 17 blocks. The pipe consumes up to 7 more. DMA lossage may consume 1 more. This doesn't leave much out of the standard 30 blocks. Perhaps the pipe blocks even get swapped to the disk :-(. My times were made with a 256K cache, so the cache should have been adequate.) Consider yourself lucky to get 17K/sec, but don't be happy with it :-). -- Bruce Evans evans@syd.dit.csiro.au