Comparison of 386 Unixes

[Ron Guilmette]

In article <9328 at dasys1.UUCP> tbetz at 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 at mcc.com
// UUCP: {rutgers,uunet,gatech,ames,pyramid}!cs.utexas.edu!pp!rfg