From: CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 23-JUN-1989 22:30
To: MRGATE::"ARISIA::EVERHART"
Subj: Re: Obscure VS2000/VWS bug
Received: From KL.SRI.COM by CRVAX.SRI.COM with TCP; Fri, 23 JUN 89 16:15:51 PDT
Received: from ucbvax.Berkeley.EDU by KL.SRI.COM with TCP; Fri, 23 Jun 89 16:09:33 PDT
Received: by ucbvax.Berkeley.EDU (5.61/1.37)
id AA29738; Fri, 23 Jun 89 15:57:43 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for info-vax@kl.sri.com (info-vax@kl.sri.com)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 23 Jun 89 16:24:38 GMT
From: mcvax!cernvax!paul@uunet.uu.net (paul burkimsher)
Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland
Subject: Re: Obscure VS2000/VWS bug
Message-Id: <1027@cernvax.UUCP>
References: <22400D56_00100388.009268E71B2501E0$17_1@UK.AC.RHBNC.VAXB>
Sender: info-vax-request@kl.sri.com
To: info-vax@kl.sri.com
Obscure VS2000/VWS bug
I'm sorry to say that upgrading won't help you.
We run VMS V5.0-2 and VWS V4.0 and still get all of the problems you both
describe. In addition, VWS$EMULATORS is prone to eating up 50% (fifty percent)
of your cpu while doing no useful work. The only way out of that one is to
reboot too.
I picked up the following:
----------------------------------------------------------------------------
Note 9.3 Bizarre behavior 3 of 7
FNALF::NAGY "Frank J. Nagy, VAX Guru & Wizard" 13 lines 20-MAY-1988 06:18
-< Try increasing PAGEDYN >-
We saw these sort of problems when we got the first workstations and
were running VWS V3.0. The problem in that case was that we had not
created enough paged dynamic memory. We increased PAGEDYN and things
got a lot better.
At the Fall '87 DECUS Symposia, the "VWS Hints and Kinks" session
provided the information that for use with VWS, PAGEDYN should run
in the range of 1.5-2.5 MBytes (with the lower range used for color
and grey scale systems for some reason).
My monochrome VS-II has 13 MB of main memory. SHOW MEMORY shows
Paged Dynamic Memory of 1901056 with 1542032 bytes in use. I frequently
run with 4-5 WTAn windows with no problems.
End of note
Note 9.5 Bizarre behavior 5 of 7
VXCRNB::TIMBL "Tim Berners-Lee CERN/DD" 11 lines 25-MAY-1988 03:52
-< Paged dymanic memory >-
In response to 9.3, Paged Dynamic memory affecting vaxstation hangs.
You mention your PAGEDYN usage as 1.5MB out of 1.9MB total. With 3
windows, I have 3.10 MB out of 3.15MB total. The 48k left decreases by
about 11k per normal 24x80 Vt200 window. When it is exhausted, an
attempt to create a new window will make it be drawn and then disappear
again.
As the wide windows hang only when sufficient other windows exist,
it certainly looks like a resources problem, but not necessarily
PAGEDYN (as when it has hung there is still PAGEDYN left).
End of note
Note 9.6 Bizarre behavior 6 of 7
20514::BUCLIN "Service Informatique, DI-EPFL" 12 lines 31-MAY-1988 15:41
-< Have you check the cluster parameters ? >-
< Note 9.5 by VXCRNB::TIMBL "Tim Berners-Lee CERN/DD" >
> As the wide windows hang only when sufficient other windows exist,
> it certainly looks like a resources problem, but not necessarily
> PAGEDYN (as when it has hung there is still PAGEDYN left).
You have mentionned that your stations were diskless. That means that
your system needs a lot of IRP, LRP for the LAVC traffic. If you use the
Workstation Option Menu to create your new window, a new process is
created too. This requires a lot of traffic to set up the swap an page area
for this process. If your look aside lists are big enough, another reason
may be found in the cluster parameters (lock manager data base, etc ...).
Note 9.7 Bizarre behavior 7 of 7
FNALC::OLEYNIK 3 lines 18-JUL-1988 14:47
-< Banner program can hang workstations >-
Workstations running "Banner" can hang up A number of workstations
running the "Banner" program have hung up. To free the station, you
must stop "Banner" from another terminal. Better yet, don't run banner.
End of note
Note 9.10 Bizarre behavior 10 of 14
FNAL::CHADWICK "Keith Chadwick, (312) 840-2498" 24 lines 18-JUL-1988 21:27
-< Parameters - More Knobs to Turn >-
Recently Frank Nagy helped me track down an intermittant problem
which would occasionally "hang" the VAXstation display when the
UIS$EMULATORS and UIS$DISPLAY_MANAGER process went into RWAST states.
The solution was to modify the SYSUAF parameters:
Parameter Old Value New Value
BIOLM 18 128
DIOLM 18 128
ASTLM 24 384
TQELM 10 32
ELQLM 50 400
While the VWS installation guide mentions that these parameters
should be increased, it would appear that the KITINSTAL.COM
does not modify the SYSUAF, thus the system manage should
review these parameters and increase them as appropriate.
I should also mention, for completeness, that another way for the
VAXstation to hang is to run out of pool. After the VAXstation
has been up for a day or so, do a SHOW MEMORY and increase the
SYSGEN parameters IRPCOUNT, SRPCOUNT, and LRPCOUNT if appropriate.
-Keith,
Note 9.11 Bizarre behavior 11 of 14
UIHEPD::DDL "Dave Lesny" 17 lines 19-JUL-1988 12:25
-< Process priority is the problem >-
We also have had problems with BANNER hanging our VAXstations. The problem
was very sporadic. Eventually I tracked it down to process priority. By default
BANNER runs at priority 1. If you are running a compute bound process at
a priority higher than 1, BANNER does not get any cpu time. If however BANNER
does get some time because the cpu bound process becomes unrunnable (does
some I/O), starts updating the display, and then the cpu bound process becomes
runnable, the entire VAXstation appears to be hung. I assume this has to do
with ASTs not being delievered to BANNER since it cannot be scheduled to run
and the I/O to the display never completes.
Since we like to use BANNER (users like the cpu histogram and clock), I
changed some defaults in BANNER.COM. I changed the priority to 4 (our normal
interactive priority - batch runs at 2), turned off the cube and changed
the update cycle to 5 seconds. Since doing this we have not had any problems
with either VWS 3.2 or VWS 3.3.
dave lesny
----------------------------------------------------------------------------
With all this received wisdom and still getting problems, we decided to
report it to DEC and sent them crashdumps.
They said:
Our SYSGEN param CTLPAGES was too small (was 500, now 1500)
Our PQL_DPGFLQUOTA too small (was 2k now 9k)
$Define/sys/exec uis$p1_pool_size N
where n=old N + 512*(your_increase_in_ctlpages)
(was 150000 now 662000)
Always re-install VWS after VMS upgrades (even minor ones).
So we did all this and we STILL get problems... :-(
My unsophisticated rule of thumb is to increase NPAGEDYN. (What? Even further?
But I've already increased it Nx100%!)
It seems to delay the evil day SOMETIMES (=but not always).
Paul Burkimsher
Cern, Geneva, Switzerland.
paul@online.decnet.cern.ch
vxcern::paul (HEPNET)
paul%online@cernvax (BITNET)
paul%cern.online@uk.ac.ean-relay (Janet)
...!cernvax!paul (UUCP)