JOHNC%CAD2.DECnet@GE-CRD.ARPA.UUCP (01/27/87)
> From: Aharon Shtull-Trauring <aharon%wisdom.bitnet@wiscvm.wisc.edu> > Subject: problems with GPX Vaxstation II > > I have set all the reasonable parameters I could think of as high as > possible given the limitations of disk and memory (pagefil,swapfil > each ~ 30,000 bytes, wsext of 6k) Performance, to say the least, > stinks. We can hang the system with ease. > (1) We can not have more than 6 windowsat one time > (2) Certain operations (e.g. scrolling a text window which overlaps a > graphics window, or sending a window of the screen - partially) causes a > large number of LRP requests which causes the system to drag to a halt. > (3) When using sements in our programs, empty segments (w/o private data) > require 2K each!!!!! Any reasonable usage of segments causes our system to > sit 95% of the time in PFW since they demand such a large amount of memory. > (4) Quickly moving a graphics window often causes it to leave "stuff" behind. We have some GPXs, and I too have noticed slow window repaints when there are overlapping windows, and particularly when the occluded window is text. However, nothing we have seen is nearly as bad as what Aron describes. He may have some very real bugs! We had some complex code which has always required adjustment (upwards!) of sysgen and uaf values on any VAX. Some of those parameters had to be adjusted even higher for the code to run on a GPX. We adjusted: Sysgen: VIRTUALPAGECNT to 16k MAXBUF to 8k WSMAX to 7k (may need to adjust PQL_DWSDEFAULT upwards if you change WSMAX) Sysuaf: PGFLQUOTA high (16k in our case) BYTLM to 10k FILLM to 60 ENQLM to 60 WSQUOTA and WSEXTENT as high as possible, up to WSMAX Hope this helps - I can't help but think that part of Aron's problem is that something is mis-tuned for his application. John Child General Electric Aircraft Engines Lynn Mass USA