Xref: utzoo comp.unix.questions:10996 comp.os.vms:11058
Path: utzoo!utgpu!watmath!clyde!att!osu-cis!killer!ames!mailrus!eecae!cps3xx!rang
From: rang@cpsin3.cps.msu.edu (Anton Rang)
Newsgroups: comp.unix.questions,comp.os.vms
Subject: Re: Do OS's slow down with age?  (was: DDJ article / UNIX vs BS/2)
Summary: Is VMS getting slower?	 Is UNIX getting faster?
	 Depends what you're doing.
Message-ID: <1472@cps3xx.UUCP>
Date: 9 Jan 89 14:43:45 GMT
References: <209@imspw6.UUCP> <12872@steinmetz.ge.com> <370@siswat.UUCP>
Sender: usenet@cps3xx.UUCP
Reply-To: rang@cpswh.cps.msu.edu (Anton Rang)
Organization: Michigan State University, Computer Science Dept.
Lines: 99
In-reply-to: buck@siswat.UUCP's message of 9 Jan 89 04:04:57 GMT

In article <370@siswat.UUCP>, buck@siswat.UUCP (A. Lester Buck) writes:
>In article <12872@steinmetz.ge.com>, davidsen@steinmetz.ge.com (William E. Davidsen Jr) writes:
>> I talked to four system managers who handle both
>> VMS and UNIX VAXen, and even those who really dislike UNIX as an
>> interface agree that UNIX will run 20-30% more users on a VAX, at least
>> when doing typical things like edit, compile, read mail, light
>> computation, etc.
>> [ ... ]
>>   The reason is that VMS has a lot of overhead in starting a process,
>> and a lot in file i/o, due to the many types of file. You have some
>> features added in VMS (which may or may not be needed), but you pay for
>> them.

  There is a lot of process creation overhead in VMS.  On the other
hand, you don't need to create a process every time you do anything
(as UNIX does).  In fact, most "basic" users (edit/compile/link) will
log in and use only their one process (or maybe two, if they have a
background editing process).
  The file I/O overhead is significantly more than UNIX's if you're
working with only sequential files--in particular, sequential text
files.  Against this, balance the capabilities of indexed files.  If
you have an application working with large indexed files, VMS gives
you much more flexibility than UNIX (which hasn't even GOT indexed
files, and won't let you control disk allocation if you want to make
them up yourself).

>I was reading an article about VMS in the November 1988
>issue of the tabloid "Computer Technology Review."
>Titled "VAX managers cautioned on accepting VMS V.5" by
>Clay Prestia, [ ... ] at the end it
>makes an astounding statement about VMS performance over
>time (quoted without permission):

>	   "As time passes, [bugs will be fixed].  The performance
>	loss probable with V.5 is a problem that one can't
>	currently expect to see resolved as time passes.  With
>	the advent of V.5, the cumulative loss of productive
>	capacity of VMS since V.3 now totals over 30% for many
>	workloads.

  When I first saw this article, I thought "Are they serious?".  After
talking with a number of VMS managers, on systems ranging from 11/780s
to 8000-series machines, I decided "No".  I couldn't figure out what
he was talking about.  The one thing that seems to slow VMS V5 over
VMS V4 are some changes in the paging algorithm--if you have a slow
disk, the extra paging under V5 is a problem.

>	   Digital could restore much of the performance loss by
>	supplying more than one variant of VMS.  As Digital
>	supplies many disparate configurations of the VAX hardware
>	platform, it ought to supply variants of the operating
>	system software optimized to each of the different
>	environments.  [ ... ]

  It's called SYSGEN.  Admittedly, the documentation on it isn't as
good as it should be, but you can tune your system to fit your
environment VERY, VERY well using it.  (When one school I was at went
from untuned VMS 4.5 ==> tuned VMS 4.5, our "performance" [rather
subjectively] went up nearly 100%.)
  You can control paging behavior (working set sizes etc.), scheduling
(quantum times etc.), file I/O (cache sizes etc.), and basically
anything else you'd want to do.  Proper tuning really, really helps.

> [ stuff about UNIX getting faster deleted ]
>Ok, so why does Unix get better with age, across architectures,
>while VMS gets worse with age, on a single architecture?

  (1) I don't believe "VMS gets worse with age" yet.
  (2) UNIX started out as a very, very ugly bunch of code--lots of
      "hacks".  As parts of it are replaced (i.e. the Fast File
      System), it's bound to get faster--what existed before was
      truly awful.  Also, the kernel code is being modified to make
      better use of the hardware over time.

>Was the 1984 Unix article a measure of the youthful Unix?
>Is VMS creaking at the joints and well into its decline?

  No.  (But then again I'm biased--I use both VMS and Unix, and really
hate Unix; compared to it, anything's an improvement.  Well, maybe not
MS-DOS.)

>What do the above comments about tuning for VMS workload
>mean, and does this have any relevance to Unix?

  See above about SYSGEN.  In Unix, you don't tune--you just assume
stuff will work.  One other thing to remember...the environments are
really targeted for different people.  Unix is just not great for
large business databases, for instance--maybe a few variants have
support for high-efficiency databases, but that's definitely few.  It
doesn't even have BATCH jobs!  (Let alone indexed files, ACLs [though
they're in a few newer versions], and identifiers.)
  My opinions only, of course.

	Anton

+---------------------------+------------------------+----------------------+
| Anton Rang (grad student) | "VMS Forever!"         | "Do worry...be SAD!" |
| Michigan State University | rang@cpswh.cps.msu.edu |                      |
+---------------------------+------------------------+----------------------+