[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

1381.0. "Slow Grafik and excess. Log.Name Translations" by STU03::RUEGGEN () Wed Sep 06 1989 08:59

 Urgent help needed!!! (strategic customer)


	Configuration is as follows,

	Vaxstation 3100 running VMS V5.1-B (Desktop-VMS)
	Display is Colormonitor

	Problem:

	I open a normal DECterm and do a type of a REGIS file.
	A X-Y axis and a curve is being drawn. This takes approx.
	8-9 Seconds.
	I open a 2nd DECterm move it a bit and do a type of the
	same REGIS file. It now takes 1min 7sec. until the picture
	is done.
	When I now click the first window and do the picture it still works OK.

	The effect could also be vice versa i.e. the first window is
	slow and the 2nd window is OK.
 	Analyzing the problem gave the following findings:

	While drawing the picture in the slow mode the process DECW$TE_1 
	is doing a very high rate of direct I/O (not disk I/O!!! I believe
	they are logical QIO's) 
	and an equally high rate of Logical Name Translations (figures are
	almost the same).
	The CPU is at about 90% doing the translations.
	When looking at sh proc/cont and using the virtual display I
	see the PC moving within the global pages.

	When drawing in the fast DECterm I see hardly any Log. Name Transl.
	and no direct I/O. The rate for buffered I/O goes up a bit.
	I enlarged the LNM hashtables and CTLPAGES but it obviously didn't
	help. (with reboot)

	The pool parameters are all OK.

	Could this be a DECWINDOWS bug?

T.R	Title	User	Personal Name	Date	Lines
1381.1		LESLIE::LESLIE	Fat was then - thinner is now	`Wed Sep 06 1989 17:58`	5
	Could be. Have you escalated this call through Field Service? Raised a QAR? - ��
1381.2	Error creating the backing store pixmap?	HANNAH::MESSENGER	Bob Messenger	`Wed Sep 06 1989 20:48`	23
	Re: .0 I haven't seen anything like this, although I have received QARs about the problem with large numbers of direct I/Os. From your description, it sounds like what might be happening is that the backing store pixmap can't be created for the second window, so an error message is logged every time DECterm tries to write to the pixmap. To verify this, you can try covering up the second window and then exposing it; if the pixmap wasn't created then the graphics shouldn't be redrawn. I assume the customer is running DECwindows V1. In DECwindows V2 you can turn off the pixmap backing store, and if DECterm can't create the backing store it doesn't try to write to it. How big are the ReGIS windows, and what other applications is the customer running? I've been able to create several ReGIS windows, each with their own backing store pixmap, but this was on a VSII/GPX with nothing else running except the session manager and window manager. There seems to be a problem where off screen memory can become fragmented, so the problem might clear up if the customer restarts the server (e.g. reboots the system). -- Bob
1381.3	This is exactly my problem	STU03::RUEGGEN		`Thu Sep 07 1989 04:39`	28
	Hi Bob, -< Error creating the backing store pixmap? >- Re: .0 >I haven't seen anything like this, although I have received QARs about the >problem with large numbers of direct I/Os. From your description, it sounds >like what might be happening is that the backing store pixmap can't be >created for the second window, so an error message is logged every time >DECterm tries to write to the pixmap. To verify this, you can try covering >up the second window and then exposing it; if the pixmap wasn't created then >the graphics shouldn't be redrawn. >I assume the customer is running DECwindows V1. In DECwindows V2 you can >turn off the pixmap backing store, and if DECterm can't create the backing >store it doesn't try to write to it. Thank you very much for your help. I have exactly this effect. Knowing this I found this symptom mentioned in a previous note (184.1). Since I am not very knowledgable in DECwindows could you give me a hint on what to do. Is DECwindows V2 available for Desktop-VMS already? Thank's in advance for any advice -Ulrich
1381.4		SITBUL::KLEINSORGE	So sue me.	`Thu Sep 07 1989 10:35`	14
	A high direct I/O rate, and logical name translation coupled with a slow and bursty output on a DECterm means that X11 errors are being logged -- usually as the result of a PIXMAP failure. What is actually happening is that a error log is being constantly opened and extended. If you Clear Lines Off Top and Reset, the problem should go away. This happens to me all the time on V5.1 GPX's, PIXMAP deletion seems to have a bug and you eventually cannot create any new PIXMAPs until you restart the server. _Fred (who figured this out from experience)