[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

Title:	DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:	See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:	STAR::VATNE

Created:	Mon Oct 30 1989
Last Modified:	Mon Dec 31 1990
Last Successful Update:	Fri Jun 06 1997
Number of topics:	3726
Total number of notes:	19516

3715.0. "DECWindows Server Performance" by CGOA01::RATHNOW () Mon Nov 26 1990 13:24

Hi All,

I have a customer with a DECWindows application that is having some performance
problems.


THE APPLICATION

The application is a general purpose graphics package.  You define the formula
to generate the points and the points are generated into an array.  The package
then pops a window with a coordinate plain and start plotting them in burst of
300 points.  It was originally written without a windows front end but it was
recently added.



THE PROBLEM

The sample run the customer showed me was simple.  He generated 10,000 random
points on a 6x6 plain and then started plotting them.

The first experiment was to run the client on an 8650 with the graphics window
being opened on a VAXStation 2000.  With only one graph being generated, it took
about a minute to gernerate the plot.  He then ran two copies of the
application, both opening the graphics window on the VS2000.  The station ground
to almost a complete stand still.  If you drove the rat into a window and
clicked to apply focus, you could go for coffee and hopefully by the time you
got back, the title bar might have lit up.  After 30 min., neither graph was
even close to being finished.  Opening windows on a VS3100 showed slightly
better performance but it wasn't anything to write home about.

I was able to run monitor in another session.  The only activity on the system
was CPU, 50% busy, all of which was being consumed by the process
DECW$SERVER_0.  MONITOR modes show that most of that time was Interrupt Stack
with the remaining time being Kernel Mode.

We then ran the same senario on the VS2000 with the same results.  This
eliminated any possible network problems.  

We also ran the same experiment using a DECStation 3100 as a server and got
perfectly acceptable results.



THE QUESTIONS

Is all this normal?  I realize that the DECStation is a different architecture
but would you expect to see such a dramatic performance degredation across
different machines?  Any suggestions as to what I could start looking at?

Thanks,
Dave.

T.R	Title	User	Personal Name	Date	Lines
3715.1	More information needed	STAR::VATNE	Peter Vatne, VMS Development	`Mon Nov 26 1990 14:46`	8
	What is the version of VMS and DECwindows in use? What kind of graphics boards are on the VS2000 and the 3100? This performance does seem very bad. I would have expected that two applications running at the same time would take about twice as long as a single application running. Can you obtain the application so we can give it a try here?
3715.2		STAR::KLEINSORGE	Fred Kleinsorge, VMS Development	`Mon Nov 26 1990 15:49`	9
	Actually I would expect it to take longer than 2x. Remember, because two applications are contending for the server, you are going to get things like GC validation happening much more frequently. Possible problems are in resource contention. Are there any PIXMAPs being used by the application? Swapping PIXMAPs is the kind of thing that can do this.
3715.3	We can deliver!!	CGOA01::RATHNOW		`Mon Nov 26 1990 19:56`	20
	Re: .1 The version of VMS is 5.3. They couldn't tell me the version of DECwindows but assured me they have installed all version and updates to DECwindows that have come with the latest releases of VMS. They have just plain vanilla VAXstations and DECstations so no graphics boards. The customer can give us a copy of the EXE if we like. They seemed a bit reluctant to give us the source but if you really want it I might be able to sweet talk them. (It's quite large BTW) Re: .2 The 2x rule holds for the DECstations but not for the VAXstations. It's more like a factor of a 100x!! They are using PIXMAPs.
3715.4	Display memory is limited	TOOLEY::B_WACKER		`Tue Nov 27 1990 12:10`	13
	> They are using PIXMAPs. Then they're thrashing pixmaps in and out of display memory. There is a couple of notes that go into it in gory detail. Also, if they have pixmaps are they drawing to both the pixmaps and the window? You'd probably get better performance from drawing to the pixmap and then copy area to the window. If the pixmaps really have to be that large then you might want to look into an SPX that has more display memory and won't thrash. Bruce
3715.5	Our best guess	STAR::VATNE	Peter Vatne, VMS Development	`Tue Nov 27 1990 13:24`	19
	If they have VMS V5.3, then they have DECwindows V2 (as far as customers are concerned, DECwindows is an integral part of VMS). The latest release of VMS and DECwindows is version 5.4. It is our suspicion that the customer does have graphics boards. You should always ask the exact model of VAXstation. For instance, we believe that they have a model VS2000/GPX and a VAXstation 3100/GPX. (One easy way to tell if they have a GPX is to ask them if they have a color screen.) GPXs will have performance problems if the customer's application uses pixmaps above a certain size. I entirely agree with Bruce that the customer is thrashing pixmaps in and out of display memory. The DECstation uses a frame buffer (i.e. no graphics board), and therefore never suffers from thrashing. As with any resource problem, the solution is either to use less of it (smaller pixmaps or no pixmaps), or get a new graphics board (the SPX) that provides more on-board graphics memory.