From: pettigrew_mi@ripple.enet.dec.com (Mike Pettigrew)
Subject: Re: RE: VMS tuning for a vaxcluster (LAVC)
Organization: Digital Equipment Corporation
Date: 28 AUG 92 17:53:34 PDT


In article <9208281916.AA02286@sndsu1.sinet.slb.com>,
 <brydon@dsny25.sinet.slb.com> writes...

> 
>Okay, but what about the situation of one satellite vaxstation on a lightly
>loaded network?  I think page read I/O's should be considered separately from
>page write I/O's.  Does this satellite system do page read I/O's any faster
>over the ethernet versus to local disk?  
>

Paging I/O takes longer from a server over the ethernet than it does from
a local disk.  There is not an easy way to separately measure page read and
page write I/O times, nor any obvious reason why they should be greatly 
different.  No one has yet noticed if this is so, though it is certainly
possible.


A satellite system that is paging any processes always seems to run slower
with a server page file than with a local page file, even when the net is
lightly loaded.  You can measure the difference in a very straightforward
manner.

It is easy to measure program run time with a server page file and then
again with a local page file.  It is somwhat difficult to make sure other
conditions remain constant, but when you do, the answers are consistent.



> 
>>What does have a very critical effect is changes to the system parameters
>>WSMAX, MPW_HILIMIT, PQL_MWSQUOTA, PQL_MWSEXTENT , and also changes to the
>>SYSUAF field WSEXTENT.  On a memory-rich system, these fields can be raised
>>to much higher values than the default calculations.
> 
>Hmmmm well agreed, it's like money.  If you have more you can spend more.  In
>my opinion Autogen does a good enough job of this except of course for
>WSEXTENT and perhaps PQL_MWSEXTENT.
> 
>>The practical effect of raising these parameters is to eliminate paging
>>and swapping activity on the sattelite nodes althogether.
>>
>>If you INSTALL all of the images that you are using on the sattelite nodes,
>>and keep a free list of about 4,000 pages, you will rapidly have all of
>>the relavent system image pages cached in the free list at the sattelite
>>node.
> 
>This sounds a bit like the old DEC sales pitch of "buy more memory".  Indeed
>it will improve matters, but that wasn't really the question being raised.
> 

  Two questions were asked:

   (1)  Do page reads work faster from a server than from a local disk
        if data blocks are cached?

        No, because you cannot cache the data blocks on the page file.
        The local page file is always faster, and measurably so, given
        equal disk drive speeds.

        If your application must page or swap, a local disk gives the
        best performance.


   (2)  Can you cache system routine pages on the server and thus improve
        performance of a sattelite node?

        No, because the system routine pages are cached on the free
        memory list of the sattelite node.

        You get best application performance by having "enough" memory
        to run it with minimal paging, and by tuning VMS to use all of
        that memory.

Some experiments indicate that you can do quite well in LAVC performance
improvements, without buying a single piece of additional hardware, by
a few simple VMS tuning changes.


Not that I would ever discourage you from buying more DEC hardware! :)

----------------------------------------------------------------------------
| -Mike Pettigrew        pettigrew_mi@ripple.enet.dec.com
|                        (206) 661-3032
|                        Digital Equipment Corporation 
|                        Federal Way, Washington, USA
|___________________________________________________________________________
|  Surprises Every Day!
|___________________________________________________________________________
|These opinions are mine and not necessarily my employer's
----------------------------------------------------------------------------