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