From:	CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 19-APR-1991 04:18:31.54
To:	ARISIA::EVERHART
CC:	
Subj:	RE: FTDRIVER versus PYDRIVER performance

From:	RELAY-INFO-VAX@CRVAX.SRI.COM@SMTP@CRDGW2
To:	Everhart@Arisia@MRGATE

Received:  by crdgw1.ge.com (5.57/GE 1.97)
	 id AA09387; Fri, 19 Apr 91 04:01:54 EDT
Received: From ENET-GW.PA.DEC.COM by CRVAX.SRI.COM with TCP; Thu, 18 APR 91 15:35:07 PDT
Received: by enet-gw.pa.dec.com; id AA03093; Thu, 18 Apr 91 15:34:25 -0700
Received: by fork-city.pa.dec.com; id AA25141; Thu, 18 Apr 91 15:34:10 -0700
Date: Thu, 18 Apr 91 15:34:10 -0700
Message-Id: <9104182234.AA25141@fork-city.pa.dec.com>
From: kenney@star.enet.dec.com (Forrest A. Kenney)
To: "info-vax@kl.sri.com"@Pa.dec.com
Subject: RE: FTDRIVER versus PYDRIVER performance


	Attached is a report written by David Jones about the supported pseudo
terminal driver performance relative to the ones provided with DECwindows.  The
bug he has found is the result of an oversight on my part in the deletion logic. 
The following patch should correct this problem.  Please be advised that the
patch has not been tested extensively, and is not an officially supported fix to
the problem. I am working on getting a supported fix to the telephone support
center in Colorado Springs.

$ patch FTDRIVER.EXE
!
!	For the driver shipped with V5.4 of VMS the offset value should 
!	be 980.  For all other versions of the driver the offset should
!	be 985.  If you are using the V5.4 version please try and get a 
!	V5.4-1 version installed and then apply the patch. 
!
define offset = 985
repl/ins offset
'movl	w^015c(r5),r4'
exit
'movl	w^0020(r5),r4'
exit
update
exit

	You will have to reboot the system after this because the FTDRIVER 
is not reloadable.  


	I also want to clarify the statement made in the release notes,  they
really do not tell the whole performance story.  The new pseudo terminal fixed
cost to set up and complete read or write request take about 800 - 1000
instructions compared to the 1300 to 1500 requires by PY/TW pseudo terminal used
by DECwindows.  In addition the new pseudo terminal provides a mode where a
pseudo terminal write can read any available terminal output.  The existing
PY/TW driver pair requires two separate $QIO requests to accomplish this.  By
combining the read and a write into a single operations the fixed cost of one 
operation can be avoided.  This can be a significant savings in certain cases.

	When designing the pseudo terminal for V5.4 we had a large body of data
that indicated that many users of pseudo terminals tended to perform small
writes to the pseudo terminal.  This  write was followed by a read completion to
that typically contained the data echoed by the terminal driver.  This resulted
in a large amount of effort focused in shortening the cost to setup and complete
a request, as well as the combined write with read capability.  For applications
that fit this model, and take advantage of the write with read capability the
performance saving can be quite significant.

	For applications that do not fit this model the performance difference
between the new supported pseudo terminal, and the PY/TW driver pair will not be
noticeable, or measurable.  What ends up happening is that the savings in the
setup and completion code are small compared to the time spent in the terminal
driver character handling code.  In fact for large reads or write requests the
mailbox driver will be much more efficient than either of the pseudo terminal
drivers.

	I hope to present a paper, on the FTDRIVER, and PTD$SERVICES at the Fall
DECUS.   The paper will cover the design considerations, performance
characteristics, and using the pseudo terminal.  


Forrest Kenney

>
>The release notes for VMS 5.4 left me with the impression that the new
>pseudo-terminal driver (FTDRIVER) was a signifcant performance improvement
>over the old PYDRIVER.  I measured the raw throughput for writes to the
>PTY (i.e. control program reads output produced by application) and got
>close to th rate for both drivers.
>
>Reading from the PTY (i.e. simulating user input), probably is faster for
>FTDRIVER, but since the ratio of writes to reads is typically very high,
>the two drivers are practially the same speed.  I could probably tweak the
>code used for testing the FTDRIVER and get a 10-15% improvement, so DEC can
>claim a faster pseudo-term, but not dramtically faster.
>
>
>I did the tests using buffer sizes for the writes of 500, 50, and 5 bytes
>on a VAXstation 3100, model 30, running VMS 5.4-2.  Transfering 500,000 bytes
>took 4 seconds, 21 seconds, and 180 seconds in order from largest to smallest
>buffer size.  I also tested a mailbox as a sink for the output and found it
>was twice as fast for the 500 byte case but only 1.5 times faster as PYDRIVER
>for the 5 byte test.
>
>Where the FTDRIVER really seems to be an improvement is in its ability
>to distinguish the read prompt that was output prior to a read.  It's a lot
>easier to follow a script when you can get the prompts without having to parse
>the output stream for in-band cues.
>
>There is a bug in FTDRIVER that causes the loss of 432 bytes of process
>BYTLM under an easily reproduced condition.  If a sub-process calls PDT$DELETE
>and terminates immediately, before the driver actually deletes the device
>(about .5 seconds on average),  the byte limit/quota deducted from the
>JIB when the UCB was created is not returned.
>
>I used the PDT routines to write a front end for non-SMG equipped utilities,
>such as SYSGEN, to give them command line recall.  When run with applications
>that don't use read-with-prompt(.e.g. programs ported from unix), it
>converts apparent prompts into actual prompts for the SMG calls.  If anyone
>wants to play with it, send me mail and I'll send you a  copy (~1000 lines,
>VAX-11 FORTRAN).  It doesn't even require any privileges.
>
>
>David L. Jones               |      Phone:    (614) 292-6929
>Ohio State Unviversity       |      Internet:
>1971 Neil Ave. Rm. 406       |               jonesd@kcgl1.eng.ohio-state.edu
>Columbus, OH 43210           |               jones-d@eng.ohio-state.edu
>
>Disclaimer: A repudiation of a claim.

