HDTenEightyP/NetNews huggingface dataset:
From: "Bob George" <BOB@aeneas.ims.disa.mil>
Newsgroups: vmsnet.internals
Subject: re: vms tuning for vaxcluster (lavc)
Date: 31 Aug 92 14:10:00 EST
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Subj:   Re: VMS tuning for a vaxcluster (LAVC)

#<brydon@dsny25.sinet.slb.com> writes:

#[much useful stuff deleted]

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

#Nope.  The local disk's still faster.  When I and a friend did VMS tuning
#studies for <a former employer> we found that even on an unloaded net the
#local disk was faster.  Mind you, this was using VAXstation IIs with between
#5 and 16MB and RD54s.  Mileage on newer systems may vary, but I'd bet that
#the local disk still beats Ethernet traffic.

[lots of interesting stuff deleted]

Am I missing something fairly obvious in this thread or on the nonlocal
paging, don't you still have to wait for a disk I/O to occur.  On top of
the overhead of setting up the ethernet packet(s), when it gets to the
node where it was going, there is still a disk I/O that needs done.  On
a page write, this activity could be buffered.  But on a page read, the
process would still be hung up until the actual disk gets read and the data
returned.  For at least moderately similar disks, this would give the
advantage to the local disks.
                                    bob

+---------------------------------------------------------------------+
|      Bob George       Internet:  BOB@AENEAS.IMS.DISA.MIL            |
|      Disclaimer:      Opinions expressed are mine and mine only.    |
+---------------------------------------------------------------------+
From: <brydon@dsny25.sinet.slb.com>
Newsgroups: vmsnet.internals
Subject: RE: VMS tuning for a vaxcluster (LAVC)
Date: Mon, 31 Aug 92 19:10:38 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Bob George (BOB@AENEAS.IMS.DISA.MIL) sez:
>#Nope.  The local disk's still faster.  When I and a friend did VMS tuning
>#studies for <a former employer> we found that even on an unloaded net the
>#local disk was faster.  Mind you, this was using VAXstation IIs with between
>#5 and 16MB and RD54s.  Mileage on newer systems may vary, but I'd bet that
>#the local disk still beats Ethernet traffic.
>
>[lots of interesting stuff deleted]
>
>Am I missing something fairly obvious in this thread or on the nonlocal
>paging, don't you still have to wait for a disk I/O to occur.  On top of
>the overhead of setting up the ethernet packet(s), when it gets to the
>node where it was going, there is still a disk I/O that needs done.  On
>a page write, this activity could be buffered.  But on a page read, the
>process would still be hung up until the actual disk gets read and the data
>returned.  For at least moderately similar disks, this would give the
>advantage to the local disks.

To restate several points I was trying to make:

(1) What is considered page/swap data on the satellite may (or may not?) be
considered cache-able data on the boot node.  Reads will probably show
different numbers from writes any way you look at it.  In a previous message
in this thread, somebody (from DEC?) indicated that there could be no caching
on either reads or writes for some reason...what is the explanation for that?

(2) Yes it takes ethernet processing, but even on a slow VMS system, this will
be on the order of a few microseconds.  Okay, say it is 100 microseconds.  One
millisecond of disk controller latency (or any other delay) is 1000
microseconds.  Access times on disks are typically 20000 to 50000 microseconds
(remember the difference between 'average access time' and 'maximum access
time' and 'typical access time').

(3) In many cases, the hardware technology on the boot node is much better
(eg. faster) than that on the satellite node.  This goes back to the birth of
the technology with 45 msec RD53/RD54s on VAXstation 2000's and 25 msec DSA
drives on an 86xx boot node.  Assume 1 millisecond for ethernet overhead and
processing.  With this configuration, 25 + 1 is much less than 45.  The access
time numbers for boot nodes versus satellites is getting closer but a
difference (based on technology) still seems to be the case.
_______________________________________________________________
Harvey Brydon         | Internet:   brydon@dsn.SINet.slb.com
Dowell Schlumberger   | P.O.T.S.:   (918)250-4312
   Reality is for those that can't handle simulation.
Newsgroups: vmsnet.internals
From: frank@rover.uchicago.edu (Frank - Hardware Hacker - Borger)
Subject: Re: DR bad, VAX PRO good
Summary: DR not bad, VAX PRO still good
News-Software: VAX/VMS VNEWS 1.41    
Reply-To: frank@rover.uchicago.edu
Organization: Joint Center for Radiation Therapy
Distribution: world,local
Date: Tue, 1 Sep 1992 20:45:00 GMT

In article <1SEP199210172255@mrsvax.mis.arizona.edu>, jms@arizona.edu writes...
>... 
>/* Now for the flame part. */
> 
	Joel then provides us with a sterling example of the fine art of the
	flame, demonstrating the special ability to reflect the flames of others
	back upon said flamer.
> 
>Put simply, gentlemen: if you knew what you were talking about, then you'd
>know how wrong you are. 
> 
>/* Ahhh, that felt good, even if it was a waste of bandwidth.  But look,
>if you insult me in public, you have to expect a public response. */
> 
	I try not to draw conclusions from single sources, but generally find
	that people who don't take the time to proofread and polish their
	postings often show the same lack of care with their code.

   Frank R. Borger - Physicist    __       Internet:  Frank@rover.uchicago.edu
Michael Reese - Univ. of Chicago |___      Phone : 312-791-8075 fax : 567-7455
  Center for Radiation Therapy   | |_) _   
    2929 South Ellis Avenue        | \|_)  Psychiatry is the care of the id by
    Chicago, Illinois 60616           |_)  the odd. - Unknown
From: pettigrew@vertex.enet.dec.com (Mike Pettigrew)
Newsgroups: vmsnet.internals
Subject: Re: VMS Tuning
Date: 26 Aug 92 17:27:43 GMT
Organization: Digital Equipment Corporation


In article <7892345@MVB.SAIC.COM>, "CCF::GPE%hermes.mod.uk"@relay.MOD.UK writes...
>Give me some feedback guys (and girls)!
> 
>......
>
>Now from time to time, too often for my liking, I see statements like the
>following in articles on VMS tuning:
> 
>"... there are often tens of thousands of pages of memory left on the free page
>list with no way for the system or processes to get to it. The goal in tuning
>memory is to free up this unused memory and make it available for the system
>and processes which can make good use of it"
> 
>If I am completely deluded in my view, will somebody please tell me!
> 

The default VMS tuning was established for memory-poor systems in the days
of VAX-780's, and MICROVAX 2000's.  It is not necessarily the most effective
tuning for a memory-rich system.

A system with WSEXTENT set to 2048 pages on most USERNAMES will never make
any productive use of available free memory during moderate baseloads, and
will be somewhat impaired by excessive traffic on the system page file.

Note that most user application images require 6,000 to 10,000 pages of
virtual memory.  The unconstrained working set of these applications 
varies quite a bit, but is usually more than half of the virtual storage.
That is what you wnat to use the "free" memory for.

The goal in tuning memory usage is to reduce or eliminate page file access
as much as possible.  One access to the page file is roughly 400 times the
delay of a 'soft' page fault.

----------------------------------------------------------------------------
| -Mike Pettigrew        pettigrew_mi@ripple.enet.dec.com
|                        (206) 661-3032
|                        Digital Equipment Corporation 
|                        Federal Way, Washington, USA
|___________________________________________________________________________
|These opinions are mine and not necessarily my employer's
----------------------------------------------------------------------------
From: GAVRON@VESTA.SUNQUEST.COM
Newsgroups: vmsnet.internals
Subject: More on the Caliber of Yoyos in Digital Review
Date: 31 Aug 92 16:12:55 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List


        More from email:

>To:    gavron@vesta.sunquest.com
>Subj:  Bill sent me this...
>
>Will you tell Ehud Gavron that he's way out of line. Does he know I was a
>former Navy Seal? Did I ever tell you about the time I faced down five Ninjas?
>I'll have you know I added a QIO function modifier to the terminal driver to
>modify a VAX 11/780 microcode on the fly to do FFT's faster than you could
>with machine code. Why I've custom machined a barrel connector so my ethernet
>could run at 15Mhz, the standard ones were just too slow. Didn't use no
>manchester encoding either Well, gotta go, I'm going to meet some pretty
>sharp high level people in the computer field, some 'market analysts' from
>the Gartner group. I don't think either of you have the technical chops to
>hang with this crowd, and they pull a lot of weight with hotshots like MIS
>directors, if you get my drift. I'm going to tell them about the time I
>toggled in a program with a loop containing a sequence of instructions
>designed to heat the processor in such a way that new traces were formed,
>creating a VAX CPU that ran up to five times faster. I just want to make
>sure you folks realize who you're dealing with.
>
>Bill Handoncock
>
>


        Ehud

--
Ehud Gavron        (EG76)
gavron@vesta.sunquest.com
"The world bores you when you're cool."
From: jeh@cmkrnl.com
Newsgroups: vmsnet.internals
Subject: Re: global vs. private pages on the FPL (was: VMS Tuning)
Date: 26 Aug 92 18:23:11 GMT
Organization: Kernel Mode Consulting, San Diego, CA

In article <1992Aug25.122200.644@cmkrnl.com>, jeh@cmkrnl.com writes:
> Pages are put at the top of the free page list when they are released at
> image rundown, or, more generally, by deletion of the virtual address space
> that describes them.  In the case of global pages, this happens when no more
> processes are mapped to the relevant global section.  So, yes, what you call
> "system owned" pages *can* be released to the top of the FPL.  It all depends
> on why the pages are being released -- working set replacement (to make room
> for a newly-faulted-in page when the working set is full) or deletion of the
> virtual address space.

Oops.  Turns out that global pages are normally released to the end of the FPL
when the last image mapped to them runs down.  (Another process might want
them soon, so VMS tries to keep them around for a while.)  But they are
released to the top of the FPL if the global section that describes them is
also deleted.

> Lots of well-known "authorities" on VMS get these details wrong, repeatedly, in
> print.  Professional courtesy prevents me from naming names.

Sigh!

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and
Chair, VMS Programming and Internals Working Group, U.S. DECUS VAX Systems SIG
Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh
From: olin@cheme.tn.cornell.edu (Steve Thompson, Cheme System Mangler)
Newsgroups: vmsnet.internals
Subject: Re: VMS tuning for a vaxcluster (LAVC)
Date: 31 Aug 92 16:36:45 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

joltes@husc10.harvard.edu writes:

><brydon@dsny25.sinet.slb.com> writes:
>
>[much useful stuff deleted]
>
>>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.]
>
>Nope.  The local disk's still faster.  When I and a friend did VMS tuning
>studies for <a former employer> we found that even on an unloaded net the
>local disk was faster.  Mind you, this was using VAXstation IIs with between
>5 and 16MB and RD54s.  Mileage on newer systems may vary, but I'd bet that
>the local disk still beats Ethernet traffic.
>

Depends on your hardware. We have a VAX 4000 model 500 with RF35's serving a
bunch of VS3100's, some with disks (RZ23) and some without. I can assure you
that the local disk is not faster in this situation. I had a diskless 3100
paging to the 4500 for a while; the machine is now at my house and has a local
RZ57 as a standalone system. It most definitely *felt* faster when it was paging
to the 4500; I have no measurements on this, however (except that an RF35 is
waaaaay quicker than an RZ57).

Steve
Newsgroups: vmsnet.internals
Subject: Re: global vs. private pages on the FPL (was: VMS Tuning)
From: jeh@cmkrnl.com
Date: 25 Aug 92 12:21:59 PDT
Organization: Kernel Mode Consulting, San Diego, CA

In article <06D94B115A9F822B58@MAX.U.WASHINGTON.EDU>,
 DEREK@U.WASHINGTON.EDU writes:
> When a
> process "gives" up a page, the memory is placed onto either the free page
> list, or the modified page list.  Process-private pages are placed at the
> head of the free page list, while system-owned pages are placed at the
> tail.  (By "system-owned pages" I mean pages which are part of an installed
> image, such as the DIRECTORY utility.)

This is not correct.  Unmodified pages that are removed from a working set by
working set replacement are put at the end of the FPL, not the beginning, and
it doesn't matter whether they were process-private or global pages. (Please
don't call the latter "system-owned", that sounds as though you mean that
they're part of the system working set.  The system working set is handled
just like a process working set as far as page replacement is concerned.)

A global page is of course not put on the FPL at all unless it's been pushed
out of the working sets of *all* of the processes that had referenced it.

Modified pages go to the end of the modified page list.  When they reach the
top of the MPL and are written back to disk, they then go to the end of the
FPL.

Pages are put at the top of the free page list when they are released at
image rundown, or, more generally, by deletion of the virtual address space
that describes them.  In the case of global pages, this happens when no more
processes are mapped to the relevant global section.  So, yes, what you call
"system owned" pages *can* be released to the top of the FPL.  It all depends
on why the pages are being released -- working set replacement (to make room
for a newly-faulted-in page when the working set is full) or deletion of the
virtual address space.

> When a process needs a new page,
> it takes it from the head of the free page list.  Thus, the system-owned
> pages are more likely to "survive" if the free page list is relatively
> large.

Right idea, wrong detail.  The pages in on the FPL that contain useful data are
more likely to survive.  It doesn't matter whether they were process-private or
global pages.

Lots of well-known "authorities" on VMS get these details wrong, repeatedly, in
print.  Professional courtesy prevents me from naming names.

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and
Chair, VMS Programming and Internals Working Group, U.S. DECUS VAX Systems SIG
Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh
From: brydon@dsny25.sinet.slb.com
Newsgroups: vmsnet.internals
Subject: RE: PATCH on ALPHA ?
Date: 2 Sep 92 12:25:04 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

In article <1992Sep1.214402.16889@eco.twg.com>, reece@eco.twg.com (Reece R.
 Pollack) writes:
> |>Besides, a lot of patches are trivial, like constant changes.  And
> |>what if I want to patch some native M64 code?
>
> I don't think I'd want to subject my customers to the headache of trying
> to manage patched images. DEC has been moving away from this as fast as
> they can, and for good reason.

You gotta be kidding!! All of the CSCPAT_nnnn kits (all of them!) are
VMSINSTAL savesets that Patch an image.  Almost everything that is done in a
VMS0nn, VMSMUPnnn and VMSUxnnn kit consists of patches.  If DEC is getting
away from the use of the PATCH utility, then every single itty bitty VMS
release and subrelease will become huge.  Can this be real?
_______________________________________________________________
Harvey Brydon         | Internet:   brydon@dsn.SINet.slb.com
Dowell Schlumberger   | P.O.T.S.:   (918)250-4312
    I'm not an actor but I play one on T... Hey!
From: DEREK@U.WASHINGTON.EDU
Newsgroups: vmsnet.internals
Subject: Re: re: PATCH on ALPHA ?
Date: Wed, 2 Sep 92 11:00 PDT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Wolfgang J. Moeller asked:

>Is there no-one who shares my view as an end-user that the ability to
>PATCH a distributed program has some value?

Oh, no.  I share the view.  I, too, have patched VMS code to fix problems --
especially when a fix was not forthcoming from DEC, or when the patch
would fix a security problem.  (Lesse, PHONE, MAIL, and DCL come to mind.)

>Sure, patching data, or NOPping instructions does not absolutely
>require a tool like MACRO32-level PATCH, but I'd rather not miss
>*some* of its features (in particular the ability to extend
>a program section).

I agree.


-Derek S. Haining
 University Computing Services
 University of Washington
 Seattle, Washington  98195
 (206) 543-5579

 DEREK@MAX.BITNET
 DEREK@MAX.U.WASHINGTON.EDU
From: robbie@winkle.bhpese.oz.au
Newsgroups: vmsnet.internals
Subject: re: PATCH on ALPHA ?
Date: 3 Sep 92 16:43:57 +1000
Organization: BHP Information Technology, Newcastle

Personally, I don't care if DEC port PATCH or not. Mostly, you have to
shutdown an application to apply a patch or an upgrade, but if it is
easier for the distributer to get me a patch rather than a recompiled
image, fine!

However, I'd like to see DEC port almost everything else first! If they're
going to spend development time, please let them spend it on porting
products that we use everyday, not products that we may be able to save
a bit of time with. It's a bit hard to patch a non-existent image!!
(Some stuff is not expected to be available until 1994! Surely you could
have sent me a CD distribution of the new images by then!)

Secondly, compare the experience of the average VMS patcher with that
of your average ALPHA patcher. I hope this doesn't offend anyones
pride too much, but I wouldn't really put a lot of trust in a patch on a
fairly new machine (You can't even buy them yet!) compared to a newly
compiled program. How many ALPHA gurus can there be in the industry by now?
And so what proportion of developers will be able to successfully make use
of PATCH?

I would hate to see us lose functionality in the move to ALPHA! That's
backward. However, there is certain functionality which is of everyday
importance and, for a majority of users, that doesn't include PATCH.
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Rob Spencer, BHP Information Technology           |   Sorry, but my .sig
Newcastle, Australia        Voice: +61 49 40 1673 |   is on .sig leave!
Bits: robbie@winkle.bhpese.oz.au                  |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: DWING@UH01.Colorado.EDU (Dan Wing)
Newsgroups: vmsnet.internals
Subject: Re: Booting MicroVAX 3400 using non-system UIC
Date: 31 Aug 92 22:41:10 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Eric J. Seeger, eseeger@ssdc.sterling.com, writes:

>Is there a way to boot up a MicroVAX 3400 running VMS V5.4 so that a
>site specific definition can reside in a different UIC group instead of
>the system accounts group.  More specifically, I am trying to define
>several specific logicals that I want to have reside in a specific
>accounts group table, and I want to define them during the startup procedure.
>What I am finding is that even if I 'set uic' to the account I want them
>to reside in they are still ending up under the system account during startup.

That's because the SYSTEM account's GROUP table is still pointing to
LNM$GROUP_000001.  "SET UIC" doesn't change where your group logical name
table is points.  Now, even if you pointed it to the correct logical name
table, or specified the table's name with DEFINE/TABLE, it wouldn't work
because the table doesn't exist.

"So we'll create it".  But the group logical name tables are created in
kernel mode....  So you have to force VMS to create the table for you.

Each group's UIC table (LNM$GROUP_nnn) is created when the first login for
that group is performed.  I believe this is performed by LOGINOUT.EXE, and
might be documented in one of the VMS manuals.

So all you need to do is create a login with a username that has the
appropriate UIC.  This is a good time to pull out our oft-misused friend
SUBMIT/USER:

  $ COPY/PROTECTION=W:RWED SYS$INPUT: SYS$MANAGER:DONOTHING.COM
  $ DECK
  $ EXIT
  $ EOD
  $ SUBMIT/noPRINTER/noLOG/USER=user SYS$MANAGER:DONOTHING.COM
  $ SYNCHRONIZE/ENTRY='$ENTRY'
  $
  $ DEFINE/TABLE=LNM$GROUP_number ...
   ...

The DCL command SHOW LOGICAL/GROUP, from the application users' username,
will show you the correct value for LNM$GROUP_number.

I'd recommend creating a separate username, with only BATCH access permitted,
which is used for performing this function (so that the "last non-interactive
login" retains its meaning).

-Dan Wing, DWING@UH01.Colorado.EDU or WING_D@UCOLMCC.BITNET (DGW11)
 Systems Programmer, University Hospital, Denver
From: MILLER@TGV.COM
Newsgroups: vmsnet.internals
Subject: Re:  MACRO32 vs. Alpha
Date: 25 Aug 92 19:26:07 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List


>From the Alpha sessions at the Spring '92 Decus in Atlanta I got the impression
>that PATCH would not be ported to Alpha/VMS due to the complexity of the images
>produced for efficent use of the architecture.

I don't see what's any more complex about the Alpha images.  I can patch
Alpha images now with the VAX patch in absolute mode, but it's a hassle
to poke in numbers instead of opcodes.

-bruce
From: murphy@npri6.npri.com (David P. Murphy)
Newsgroups: vmsnet.internals
Subject: Re: DETACHED process -> INTERACTIVE
Date: 23 Aug 92 22:07:31 GMT
Distribution: world
Organization: NPRI, Alexandria VA


>>>How can I change the mode of a process from DETACHED
>>>to INTERACTIVE [and so on]

>>murphy@npri6.npri.com (David P. Murphy) writes:
>>[Serious hackery deleted]

>Am I just being naive, or isn't it easier just to start an interactive 
>process in the first place?  Something along the lines of:
>[macro code deleted]
>
>Don Stokes, ZL2TNM (DS555) don@zl2tnm.gen.nz

good question.  the literal answer is "yes".  the full answer is that
the detached processes in my code were being created (and then hibernating)
before the user logged in, so the terminal's device name which would be
used by any given process could not easily be predicted in advance,
so we just created normal detached processes and then changed them
to interactive when assigned to a true interactive process.

ok
dpm
-- 
murphy@npri6.npri.com 602 Cameron St. Alexandria, VA 22314 (703) 683-9090

              When every one is dead the Great Game is finished.  Not before.
                              --- Hurree Babu, "Kim"