Xref: utzoo comp.unix.xenix:5672 comp.unix.microport:3160
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!pp!riunite!rfg
From: rfg@riunite.ACA.MCC.COM (Ron Guilmette)
Newsgroups: comp.unix.xenix,comp.unix.i386,comp.unix.microport
Subject: Re: Comparison of 386 Unixes
Message-ID: <174@riunite.ACA.MCC.COM>
Date: 14 Apr 89 21:17:25 GMT
References: <4160@stiatl.UUCP> <717@pcrat.UUCP> <2354@van-bc.UUCP> <9328@dasys1.UUCP>
Reply-To: rfg@riunite.UUCP (Ron Guilmette)
Organization: MCC  Austin, Texas
Lines: 47

In article <9328@dasys1.UUCP> tbetz@dasys1.UUCP (TOM BETZ) writes:
>
>For a much better comparison, see the recent issue of MIPS
>Magazine (April?  May?  I don't have it at hand...) wherein all
>currently available 386 *NIXs are compared using a much more
>consistent environment and test suite.

I just received a reprint of the MIPS article today from the ENIX
people.  They are sending it out as a part of their marketing materials
to anyone who inquires about ENIX.

I'm not sure yet if this is really any better than the UNIX Today
article which has been bashed here recently.  Unless I'm mistaken
(which I may be because I only skimmed the article) I think that
the timing tests are all very suspect.  Why?  Well, it seems that
for some of the UNIX's, it was *faster* to *copy* a 50000 block
file than it was to just *read* it.  Does that make any sense to
anybody else?  Did I mis-read the article?  Sounds like smoke and
mirrors (and disk block caching interference) to me.

I think that if you are going to do reasonable
disk I/O speed tests that you have to somehow factor out any apparent
speed changes which arise from (a) disk block buffering/caching, or
(b) absolute locations of the particular blocks accessed (i.e. near
or far from the center of the platters), or (c) relative locations
of the particular blocks accessed (i.e. near or far from each other...
which can affect total seek time dramatically).

Perhaps the only totally fair way to run such a test is (a) always
perform the test immediately after booting to assure that the disk block
cache is effectively flushed (i.e. no blocks from the file to be
accessed are in the block buffer), and (b) do the read/write operations
on a second totally empty drive so that the locations of blocks
are the same for all tests (unless the particular OS being tested
uses a unique algorithim for allocating new blocks).  It would also
be a good idea to quote numbers when doing I/O both to a file on a
formatted drive with a filesystem on it *and* to a raw disk device.
I/O to/from a raw second drive, either reading and/or writting to/from
physical blocks 0 through N would probably tell you a lot more about
the true speed of the OS's disk I/O than anything else I can think
of.

-- 
// Ron Guilmette  -  MCC  -  Experimental Systems Kit Project
// 3500 West Balcones Center Drive,  Austin, TX  78759  -  (512)338-3740
// ARPA: rfg@mcc.com
// UUCP: {rutgers,uunet,gatech,ames,pyramid}!cs.utexas.edu!pp!rfg