RE: Unix runs faster, maybe (was: Re: Educating potential VMS users)

-----Original Message-----
From: Bill Todd [mailto:billtodd@xxxxxxxxxxxxx]
Sent: June 5, 2006 8:09 PM
To: Info-VAX@xxxxxxxxxxxx
Subject: Re: Unix runs faster, maybe (was: Re: Educating
potential VMS users)

Main, Kerry wrote:
-----Original Message-----
From: Bill Todd [mailto:billtodd@xxxxxxxxxxxxx]
Sent: June 4, 2006 5:42 PM
To: Info-VAX@xxxxxxxxxxxx
Subject: Re: Unix runs faster, maybe (was: Re: Educating
potential VMS users)

Main, Kerry wrote:

...

Point is that when both UNIX and VMS are setup and tuned
appropriately
on the same HW, there is not much difference in performance.
The point, of course, is that while virtually *any*
half-competently-implemented OS will be
performance-competitive with any
other *when set up and tuned*, *most* use of OSs is in
installations
which are *not* 'set up and tuned appropriately', but rather
either just
booted up and run or, at most, given some very general
tweaking that
won't compromise any of the many applications they're
likely to run.

And under those circumstances, VMS comes out rather poorly
performance-wise when compared to Unix, while providing
rather limited
increased reliability of a statistical sort - e.g., that
it's *less
likely* by X% that the data you naively thought you wrote
won't be on
the disk after, say, a power failure, rather than of the far more
significant variety that if the data you naively thought you
wrote isn't
on the disk after a power failure, you should file a bug report.

'A bit better reliability with a lot slower performance'
really isn't a
*default* trade-off one can legitimately boast about, I'm
afraid: one
should instead pick something closer to one extreme or the
other as the
default so that not *all* customers need tweak the system
significantly
to get something reasonable - especially since applications
with special
needs have the ability to attain them *regardless* of how
the system
defaults are set up, so really don't derive much aid from half-way
default measures anyway.

The bottom line is that Unix provides significantly better
file-system
performance out of the box than VMS does, and this is an entirely
legitimate knock on VMS - not so much on VMS's capabilities
per se as in
its choices of defaults, but the effect on real-world
perceptions is not
markedly different.

- bill


Well, my experience is that, regardless of what platform is
used, most
production shops in med-large shops will always tune their
environment
to some basic level.

1) It's not clear exactly how that statement differs from
what I said
just above ("some very general tweaking that won't compromise
any of the
many applications they're likely to run"). Tuning an entire
server for
one specific application may occur more frequently in Windows
environments (where admins are frequently scared to run more than a
single application on the server), but far less so in the
Unix and VMS
environments under discussion here.

2) One might also ask just how much of that experience was focused
solely on VMS, which *definitely* requires performance tuning when
performance is required to a significantly greater degree
than Unix (or
even Windows, God forbid).


Even UNIX and Windows servers performance can be
significantly enhanced
with some basic tuning as compared to "out-of-the-box" parameters.

I'll ask you to provide specific examples, especially in the case of
Unix: my impression is that their defaults are rather
performance-oriented (to the degree that 'significant'
enhancement might
be somewhat difficult to attain with only 'basic tweaking').


I am sure most UNIX admins would not simply install their
UNIX OS and
then start loading app's for testing without adjusting OS
and/or kernel
parameters to make the target apps work better.

I'm not so sure (especially by comparison with what may typically be
required on VMS, given that some of its defaults - e.g., RMS buffer
sizes - aren't particular desirable for *any* situations, having been
established back when RAM was added in units of KB rather than MB or
GB), but let's let people with more experience in that area
than either
of us has chime in here.


Having stated this, the performance numbers for the
majority (70-80%) of
Windows servers today are 10% to 15% busy in peak time and
majority of
UNIX servers are only slightly better at 20-30% busy in peak times.

Well, duh: what part of the fact that even with well-optimized file
access waiting for disks *still* dominates a lot of workloads has
managed to escape you? For quite a few years now it has become
difficult to purchase a processor *weak* enough to be
challenged by such
workloads (save in situations where they scale up
sufficiently to allow
that single processor or small MP system to service many, many
actively-working disks at once).

Note that in such environments having an efficient file
system *still*
makes a significant difference to system throughput, though - even if
the processor is still loafing a lot of the time. And that advantage
remains even under the virtual consolidation scenarios which you're
touting (though diverging from the topic under discussion by
doing so).

- bill


The environments I am talking about in the majority of Windows/UNIX
servers today are not CPU lite, but disk IO heavy. They are just not
utilized that much at all in peak periods - period.

Part of this might be attributed to the one-app, one server philosophy
as repeated refreshes makes for a much faster server at lower costs, but
if the workload does not increase that much, then the overall
utilization goes down. Multiply this by hundreds of x86 servers in many
environments and you have one of the basic reasons why CIO's are so
concerned about their Windows environments.

Repeated one-app, one server refreshes will mean even lower utilization
rates in the future.

And btw, a server with low cpu utilization, but heavy IO makes for a
poor candidate for virtualization. Remember that virtualization adds
another level of overhead for both IO and CPU loads. It is a trade-off -
not everything about virtualization is a good thing.

Regards

Kerry Main
Senior Consultant
HP Services Canada
Voice: 613-592-4660
Fax: 613-591-4477
kerryDOTmainAThpDOTcom
(remove the DOT's and AT)

OpenVMS - the secure, multi-site OS that just works.
.

Relevant Pages

  • Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)
    ... Subject: Unix runs faster, maybe (was: Re: Educating ... And under those circumstances, VMS comes out rather poorly performance-wise when compared to Unix, while providing rather limited increased reliability of a statistical sort - e.g., that it's *less likely* by X% that the data you naively thought you wrote won't be on the disk after, say, a power failure, rather than of the far more significant variety that if the data you naively thought you wrote isn't on the disk after a power failure, you should file a bug report. ... Tuning an entire server for one specific application may occur more frequently in Windows environments, but far less so in the Unix and VMS environments under discussion here. ...
    (comp.os.vms)
  • Re: "Shanghai Stock Exchange" and OpenVMS
    ... The VMS User's manual is. ... So Unix was a progress. ... and 2-letter commands and options. ... trying to show through photography what it's like in another context ...
    (comp.os.vms)
  • Re: 3B2 Disks
    ... Considering the nature of connectivity over the INTERNET, ... I never ran VMS -- or even accessed a machine running it. ... quite happy on even an old v7 unix machine would bring VMS to its knees. ... I actually have such as set of Qbus cards too. ...
    (comp.sys.3b1)
  • Re: "Shanghai Stock Exchange" and OpenVMS
    ... The VMS User's manual is. ... So Unix was a progress. ... and 2-letter commands and options. ... trying to show through photography what it's like in another context ...
    (comp.os.vms)
  • Re: "Shanghai Stock Exchange" and OpenVMS
    ... in this day and age Linux is the most common form of Unix then you ... Linux and VMS are not sold to the same class of users. ... Guess it depends on the style of manuals you are used ...
    (comp.os.vms)