From: <brydon@dsny25.sinet.slb.com>
Newsgroups: vmsnet.internals
Subject: RE: VMS tuning for a vaxcluster (LAVC)
Date: Fri, 28 Aug 92 14:01:37 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Somebody (looks like gjc@mitech.com) says:
>This talk about FPL etc has reminded me to ask a question
>about VAXCLUSTER (LAVC) behavior.
>
>The behavior of the VMS memory management with respect to the FPL
>and installed images is said to reduce the amount of disk activity
>required when activating commonly used images, as long
>as the amount of free pages available allows pages from your favorite image
>to remain in the FPL.
>
>Correct?
>
>Now. My question is, what good does this do in a VAXCLUSTER environment,
>specifically a LAVC environment? Here a page fault consists
>of both a trip over the ethernet and a trip to disk.
>
>Obviously if a satelite has the pages of an image already in memory,
>then you will winning big, avoiding a trip across the ethernet and everything.
>
>But what about the trip to disk? Is there a way to avoid that?

I'm having a hard time understanding your question.  Please elaborate...

>The LAVC server node may have plenty of free memory, but it may have *never*
>activated any of the images that people on the LAVC's are interested in.
>
>Even if it had activated those images, would there be any optimization
>available? (That is, does the vaxcluster lavc disk server -know- that
>pages from a disk file may already be available in memory?)
>
>My current situation is that I have a VAXSTATION-3200 with plenty
>of free memory serving as a LAVC boot node, and I'm interested in
>any hacks available to speed things up.

Increasing the size of the file system caches on the 3200 would probably do
something for you.  Sysgen parameters ACP_*.

>In VMS 5.4-3 I was using the hack of having all images from SYS$SYSTEM
>and SYS$SHARE also available on the local hard disk. That is a bit hackish,
>so I didn't bother re-doing that for VMS 5.5.

I'll bet that your V5.4-3 optimization was actually slowing things down.  My
unproven contention is that paging (and image activation) through ethernet is
actually faster than to a local disk (assumption: disks on a local workstation
are slower than on the boot server).

Really the only things that the NI port driver does is the same things that
the CI port driver does.  And all that CI driver does (for this purpose) is
talk to an HSC-xx device through the CI.  When the CPU makes a request for
disk information, the HSC is really a disk block server, not a file server.
The logic on a boot server turns it into a file server.  The major 'smarts'
are in VMS, not the HSC.  MSCP is some of these 'smarts'.  Seems to me that
paging from a satellite shows up on the boot node as [MSCP?] requests for
particular disk blocks, not as requests for file 'x' in directory 'y'.  I
don't think the NI port driver on the boot node does any translation (Can
somebody with source listings confirm or deny this?).  But I believe if the
boot node gets 2 subsequent requests for block 'n', it can pull the second one
from cache.  Correct?

Disk access times (read/write) are measured in milliseconds. Ethernet
transactions are on a microsecond level.   When a satellite pages onto its
local disk, it is doing I/O's of probably 20-40 milliseconds average (depends
on a number of things).  When a satellite pages through ethernet to another
system, the data is seen as MSCP info (?) on the boot node and (1) write times
are essentially the speed of the boot server disk, (2) reads are considered
user data on the boot server and are cached.  Therefore a page read request
from a workstation for data that is cached on the boot node could be on the
order of several hundred microseconds, significantly faster than a disk access
to the local disk.

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

Any disagreements with the above?  Anybody do any quantitative testing on
this?
_______________________________________________________________
Harvey Brydon         | Internet:   brydon@dsn.SINet.slb.com
Dowell Schlumberger   | P.O.T.S.:   (918)250-4312
I bought my VAXstation from my uncle on his deathbead - I wrote him a check.