NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/vmsnet/internal/1216

Internet Message Format | 1992-08-29 | 4.7 KB

Path: sparky!uunet!elroy.jpl.nasa.gov!ames!network.ucsd.edu!mvb.saic.com!macro32
From: <[e-mail]>
Newsgroups: vmsnet.internals
Subject: RE: VMS tuning for a vaxcluster (LAVC)
Message-ID: <[e-mail]>
Date: Fri, 28 Aug 92 19:16:25 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List
Lines: 81

In article <[e-mail]>,  I
([e-mail]) said:
>My claim is that paging through [an unloaded] ethernet is faster than to a
>local disk.  Of course if a lot of systems page this way, you will have a
>network contention problem which will slow things down.  [By the way, this
>assumes paging to another VMS system.  Paging to an Infoserver, as per the
>VXT2000 workstation is essentially the speed of the disk on the infoserver,
>plus you are generating ethernet traffic.  There is no caching on an
>Infoserver.]

Before everybody jumps on me, I don't endorse the idea of paging over ethernet
for anybody with more than a few systems.  Certainly any site with a large
number of systems connected should require local disks for paging/swapping.  I
also will say that I don't like what goes on with the VXT2000 and don't
recommend any site use any more than a couple of them.

Having made that disclaimer, Mike Pettigrew ([e-mail])
says:
>Experiments with a production system of approximately 120 VAXstations on
>a LAVC, show that local page and swap files consistently offer better
>performance than paging or swapping to disks on the server.

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?  [I would imagine that page write
I/O's would be dependent entirely on the relative disk speeds of the local
versus boot node disk speed.]

>Caching adjustments on the server, beyond the defaults computed by AUTOGEN
>did not appear to have a critical effect on performance.

Of course this would depend on the percentage of disk activity on the boot
node that is relevant to the satellite.  And I think it would only affect read
I/O's from the satellite...

>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.

>Ethernet bandwidth is comparable to the disk transfer speeds, thus light
>access to COM files and incidental data files is as fast from the server
>as it is from a local disk.  If you have lots of users, and your applications
>have many COM files, you will run into problems with seek contention, and
>should consider local disks.  If you have an application that uses many data
>files or is I/O intensive, you will have seek and bandwidth contention, and
>again should consider local disks.

This brings up another good point about images versus non-images.  The only
files that can be 'installed', 'header-resident' etc. are executable images
(okay and global sections and stuff).  With a few exceptions, you can't
'install' a data file or command procedure for performance purposes like you
can an image.

About the bandwidth issue:  Indeed the bandwidth of ethernet versus disk
accesses are about the same but on a disk access you have some relatively
expensive things going on before the data transfer:  seek time, latency,
controller and CPU issues.  This kind of overhead of course goes on with
ethernet but at microsecond speeds rather than millisecond.

Agreed that contention for any resource will always slow you down.
_______________________________________________________________
Harvey Brydon         | Internet:   [e-mail]
Dowell Schlumberger   | P.O.T.S.:   [phone]
 "Live free or die" - on license plates made by convicts