Path: utzoo!attcan!uunet!wuarchive!brutus.cs.uiuc.edu!apple!netcom!hinton From: hinton@netcom.UUCP (Greg Hinton) Newsgroups: comp.os.minix Subject: Re: Disk performance under Minix Message-ID: <2150@netcom.UUCP> Date: 18 Aug 89 02:55:58 GMT References: <21290@louie.udel.EDU> <18613@princeton.Princeton.EDU> Reply-To: hinton@netcom.UUCP (Greg Hinton) Organization: NetCom -- San Jose, CA Lines: 37 In article <18613@princeton.Princeton.EDU> nfs@notecnirp.UUCP (Norbert Schlenker) writes: >In article <21290@louie.udel.EDU> HELMER%SDNET.BITNET@vm1.nodak.edu (Guy Helmer) writes: >>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. . . . . >The copy through the buffer >cache struck me as another possible culprit Considering that DOS uses a write-through cache -- i.e. writes are NEVER delayed -- I don't see how MINIX's delayed-write cache could possibly contribute to a slowdown in output. All other things being equal, doesn't a delayed-write cache guarantee higher throughput? In article <2131@ditsyda.oz> evans@ditsyda.oz (Bruce Evans) writes: >(Remove the >WRITE_IMMED's from all but the super block and map blocks in fs/buf.h.) >It had an immediate huge effect on the time for "rm *" in a bug directory. . . . . >I also changed the cache flushing method so all dirty blocks on a device >are flushed whenever one needs to be flushed. Bruce, do you have actual timings to show how much performance is increased? Does it approach DOS' performance? One other major difference between the two operating systems is that I/O in DOS is generally not interrupt driven. I haven't looked at the actual disk I/O code in the ROM BIOS, but I wouldn't be surprised if it sits in a tight little loop, polling the disk controller, until I/O completes. This is much faster than responding to interrupts. But, of course, preemptive multitasking operating systems don't have this luxury. -- Greg Hinton INET: hinton@netcom.uucp UUCP: ...!uunet!apple!netcom!hinton