[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

1700.0. "DECW$SERVER_RETRY_WRITE_MIN on uws2.1" by MISFIT::SALEHIM (Mike Salehi) Wed Nov 08 1989 15:11

Greetings,
    
    	What is the equivalant of the following logicals on PMAX and
        where/when they should be defined. This is decwindows v1.
    
    
	Logical				Default		Units

	DECW$SERVER_RETRY_WRITE_MIN	 15000		1/10000th seconds
	DECW$SERVER_RETRY_WRITE_MAX	300000		1/10000th seconds
    
    Under VMS these logicals would be defined in the DECW$SERVER0_TABLE
    logical name table  and it is suggested they be defined by the
    DECW$PRIVATE_SERVER_SETUP.COM  procedure that is located in
    SYS$MANAGER: (note that the logicals probably  should be defined on a
    node specific basis).
    
    Mike

T.R	Title	User	Personal Name	Date	Lines
1700.1	I don't think Ultrix has the problem	DECWIN::FISHER	Burns Fisher 381-1466, ZKO3-4/W23	`Wed Nov 08 1989 17:00`	8
	I don't believe they exist on Ultrix. The problem showed up much more on VMS because of the record-oriented nature of VMS I/O. It may be that Ultrix DECnet would have similar problem, but I have not heard of it. Anyone from Ultrix reading this file and know for sure? Burns
1700.2		SMURF::DIKE		`Thu Nov 09 1989 07:23`	2
	What is their purpose? Jeff
1700.3		DECWIN::FISHER	Burns Fisher 381-1466, ZKO3-4/W23	`Thu Nov 09 1989 13:13`	19
	In the VMS DECnet transport, it was possible (in fact fairly frequent in V5.1) for the client and server to get into a deadlock with the server blocking trying to write to the client and the client blocking trying to write to the server. The retry_interval told how often to retry the write when this happened. The retry max stuff told how often to try before deciding that it was really a deadlock and not a transient condition. One reason this happened frequently was (as I understand it) because the record-oriented transfers of DECnet tended to use lots of buffer space when sending stream-oriented X data, so blocks happened ~frequently. The DECnet transport is now fixed to pack data better. TCP was always stream oriented, so it does not show this problem often. Note, though, that it can still happen on any xport and any os. I think that the MIT server actually allocates memory and saves events away if it can't deliver them. A different, but nonetheless bad thing will happen if clients don't respond... Burns
1700.4		FLUME::dike		`Thu Nov 09 1989 16:25`	3
	The last I heard, the Ultrix servers dump a client if they can't write on the connection to the client, so those retry things are irrelevant. Jeff
1700.5	ncp set exec pipeline quota 16384	MIPSBX::thomas	The Code Warrior	`Thu Nov 09 1989 22:20`	7
	DECnet-ULTRIX doesn't suffer from the same affliction that DECnet-VMS does. However it does (IMO) have a too small pipeline quota, by default (4096). 16384 is by far a more reasonable number. matt [ULTRIX NSP (aka the thing X uses)]