Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!gatech!udel!princeton!notecnirp!nfs From: nfs@notecnirp.Princeton.EDU (Norbert Schlenker) Newsgroups: comp.os.minix Subject: Re: Disk performance under Minix Summary: Can someone explain it? Message-ID: <18613@princeton.Princeton.EDU> Date: 14 Aug 89 15:20:05 GMT References: <21290@louie.udel.EDU> Sender: news@princeton.Princeton.EDU Reply-To: nfs@notecnirp.UUCP (Norbert Schlenker) Organization: Dept. of Computer Science, Princeton University Lines: 41 In article <21290@louie.udel.EDU> HELMER%SDNET.BITNET@vm1.nodak.edu (Guy Helmer) writes: >Bruce Evans' work on improving floppy disk performance got my curiosity >up, so I did a little unscientific test of i/o to my hard disk under >Minix and PC-DOS. I wrote a little program that wrote 256 1024-byte >blocks to a file using fopen/fwrite. Under PC-DOS, this program >took 5 seconds to write the file. Under Minix, this program took >18 seconds to run. This is on a 20Mhz 80386 machine with standard >AT-style controller and a 40Mb ST-251 disk with 1:2 interleave. >The 1:2 interleave is optimum for DOS; I suspect that it is too >tight for Minix. Has anyone tried fiddling with the interleave (or >the AT disk driver) to improve disk i/o? Does Bruce's protected mode >fixes (with associated improved interrupt code) improve the disk i/o >situation by reducing the time the kernel spends working (thereby improving >the optimum interleave factor)? > >-- Guy > BITNET: HELMER@SDNET This seemed a bit curious to me, so I tried it on my system too (16MHz 80386 with a Conner drive and RLL controller that appears to cache tracks). A DOS program finishes in about 6 seconds; a Minix program takes 20 seconds (elapsed) / 5.8 (user) / 0.6 (system). If I use my own stdio package (ANSI standard, as Posix standard as I can make it, with debugging if you want it and none if you don't, and numerous other improvements --- but not quite ready to post) with no debugging, I can reduce the Minix time to 17/4.0/0.6. The numbers certainly indicate that the single threaded file system has got to be replaced! But doing that won't affect these numbers, as the test was run as (essentially) the only process in the system. Bruce Evan's protected mode fixes don't affect the times substantially (the numbers above are in protected mode; vanilla 1.3 is similar). Interleave isn't a factor on my system. The copy through the buffer cache struck me as another possible culprit, but shouldn't the system times be higher if so (not that I have confidence in time accounting)? So where is the slop? I've looked at at_wini() - it's not a terribly complex piece of code. What could it be doing that would make fixed disk performance so lousy? Ideas, anyone? Norbert