| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 109.1 | Good luck! | A6INTR::SOCHA | Out in the Field | Thu Feb 02 1989 11:35 | 8 |
| You are going to have a tough time getting any decent performance.
The minimum recommended memory for stand alone systems is 6MB and it is 8MB
for clustered workstations. We tried getting DECwindows up on a 4MB VS2000
in a cluster and gave up! Your only hope is to run everything possible
on remote nodes and just use the workstation as a window server.
Kevin
|
| 109.2 | | DECWIN::FISHER | Burns Fisher 381-1466, ZKO3-4/W23 | Thu Feb 02 1989 13:46 | 5 |
| Please read the Sales Update article on performance around note 11 (topic label
is something like "official documents".
Burns
|
| 109.3 | Will ELN help? | DELNI::MHARRIS | Mark Jay Harris, Term Srvr Mktg Mgr | Mon Feb 06 1989 21:54 | 8 |
| Seems to me there was a discussion about en ELN DECwindows
implementation. If it exists, you could run the 4MB VAXstation
as a standalone DISPLAY SERVER... all applications could then
point to it.
Check the directory over the past few weeks.
|
| 109.4 | Swap 'em! | DSM::CRAIG | Nice computers don't go down :-) | Wed Feb 08 1989 21:29 | 47 |
| F.W.I.W. - I found that I greatly improved performance (i.e,
responsiveness) on my 6 MB clustered MV2000 by forcing swapping,
rather than letting the system page. It seemed kinda counter-intuitive
at first, but I discovered that I actually decreased paging
significantly, and got more USER-mode CPU, and that the jobs which
were getting swapper were generally jobs I didn't care about much.
Here's the pertinent parts of my MODPARAMS.DAT file:
maxprocesscnt = 37
balsetcnt = 16
And this is what the system looks like with a session manager and
3 DECterm windows running:
VAX/VMS V5.0-2D1 on node POLIO 8-FEB-1989 21:25:59.80 Uptime 5 06:57:03
Pid Process Name State Pri I/O CPU Page flts Ph.Mem
2CE00041 SWAPPER HIB 16 0 0 00:01:20.89 0 0
2CE00046 ERRFMT HIB 8 4052 0 00:01:09.09 76 97
2CE00047 CACHE_SERVER HIBO 16 -- swapped out -- 94
2CE00048 CLUSTER_SERVER HIB 9 88 0 00:00:21.41 138 207
2CE00049 OPCOM HIB 8 1337 0 00:01:25.16 449 171
2CE0004A JOB_CONTROL HIBO 10 -- swapped out -- 401
2CE0004B CONFIGURE HIB 10 62 0 00:00:00.71 112 154
2CE0004C SMISERVER LEF 8 198 0 00:00:04.21 591 421
2CE0004D SYMBIONT_0001 HIBO 9 -- swapped out -- 48
2CE0008E DSM_DEMON_320 HIB 14 97 0 00:00:02.69 568 256
2CE0008F DSM_GARCOL_320 HIB 4 7 0 00:00:03.86 414 256
2CE00090 DSM_LOCKMAN_320 HIBO 14 -- swapped out -- 207
2CE00091 CRAIG LEF 5 959 0 02:13:12.35 11996 967
2CE00052 NETACP HIB 10 311 0 00:12:11.95 65743 350
2CE00053 EVL HIB 6 220 0 00:00:44.79 119094 43 N
2CE00057 REMACP HIBO 13 -- swapped out -- 48
2CE00058 DECW$SERVER_0 HIB 7 13485 0 01:20:16.46 35407 1360
2CE00099 DECW$WM_1 LEF 7 51 0 00:01:01.97 4155 650
2CE0009B DECW$TE_1 LEF 5 89506 0 00:32:17.83 6010 1432
2CE0009C CRAIG_TWA9 LEF 4 35108 0 00:07:35.66 25437 150
2CE0009D CRAIG_TWA10 LEFO 4 -- swapped out -- 131
2CE000DE CRAIG_1 CUR 7 13 0 00:00:00.89 277 263 S
2CE000A1 CRAIG_TWA11 LEF 4 51007 0 00:10:06.11 43862 279
I've been running this way for about 6 months now, very satisfactorily.
Hope this helps,
Bob
|
| 109.5 | help! with performance | SSDEVO::PFROMER | Ed Pfromer, HSC S/W Development, dtn 522-6331 | Sun Mar 19 1989 14:45 | 12 |
|
I have a 16 meg uVAX II running VMS 5.1 and DECWINDOWs and the
performance is less than spectacular. Unfortunately, I have
minimal system management experience and very little time to
learn. Can someone please send me (SSDEVO::PFROMER) their
optimized MODPARAMS.DAT and any other relevant information?
Some more information: 1 RD54 (system disk)
1 RD53 (user disk)
page file = 40K blocks
swap file = 7K blocks
|
| 109.6 | What's the display device ? | AUNTB::WARNOCK | Todd Warnock @CBO | Sun Mar 19 1989 17:57 | 12 |
| A 16MB MicroVAX II running DECwindows doesn't mean much unless you
huave a display device somewhere. Is the microVAX II a boot node
for an LAVC, or just a remote DECwindows server ? More information
about your display device would help.
In general, running AUTOGEN should give you pretty good performance.
A MODPARAMS.DAT won't help unless the configuration is *exactly*
like yours - it's dependent on the hardware configuration and load
of the machine.
Todd
|
| 109.7 | slow scrolling affected by window position? | WYNTON::BMCWILLIAMS | Improvise if you have to ... | Fri Oct 27 1989 16:01 | 17 |
| I'd like to re-open the topic of DECwindows tuning ...
My biggest gripe with DECwindows is the slowness with which the screen scrolls.
Is there anything (besides acquiring more memory) I can tweak to speed up
scrolling? (I tried the UAF settings suggested in the Sales Update article
posted in 281 to no effect.)
When I was running VWS, scrolling was always slower if windows overlapped at
all or if you placed things like icons or the banner in a "bad" place. I
haven't noticed that scrolling under DECwindows speeds up any if I change the
placement of items on the screen. Is there some such quick fix I'm missing?
I've got a standalone, networked VAXstation II with 9 Mbytes RAM running VMS
5.1 and DECwindows v1. My primary application is TPU.
Brian
|
| 109.8 | | QUARK::LIONEL | Free advice is worth every cent | Fri Oct 27 1989 16:51 | 10 |
| Re: .7
Try setting the Batch Scroll value to 5 or 10 in the Display dialog
box of the DECterm Customize pulldown.
I've run with this for a while and have no complaints about the speed of
scrolling on my VS_II.
Steve
|
| 109.9 | | FK::FRED | So sue me. | Fri Oct 27 1989 19:42 | 36 |
| A large "batch scroll" is the only way that you will EVER get a
monochrome VSII to work for crap running DECwindows. Heres the
problem:
The QVSS has a "scanline map", each scanline (the full width of
the screen) is mapped to memory with mapping registers which
determine the start of the bits for each line. If you notice,
all of the screen backgrounds on VWS for the VSII are such that
the pattern bits are identical in each vertical column. Thus if
there are NO windows on either side of your window VWS will scroll
by twiddling the scanline map. But, if there IS an overlap, the
scroll must be done by MOVC/INSV instructions of the bitmap and
is bandwidth limited by the Q-Bus.
Now (you see where this is going) X11 allows the root to be arbitrary.
In addition, the VSII was dying technology when DECwindows started
development (the VS2000 has no scanline map). So... ALL scrolls on
DECwindows on a monochrome system are block moves.
Now, even better. If you can manage to align the window on a byte
boundry. And even better if you can make the inside width a multiple
of 8, then it's just MOVC's. Otherwise you must do INSV's at the
start and tail of the bitmap copy.
Also, on a VSII/GPX there "may" be a speed advantage to aligning on
a 4-bit boundry because of weirdness in the design of the dragon.
But in BOTH cases, you will NEVER get quite the hit that you get on
VWS for backing store when you have overlapping windows... though on
a dragon the X code "may" be drawing everything and letting the dragon
clip which could give you a performance loss in that case.
In short, get a VS3100.
Good Luck.
|