.NO PERIOD
.PAGE SIZE 58,65
.RIGHT MARGIN 65
.RIGHT;VAX/VMS
.RIGHT;Timings
.B 3.C;ACNET Design Note No. 16.0
.B.C;^&VAX/VMS System Service Timings\&
.B.C;Frank J. Nagy
.FLAGS SUBSTITUTE
.B.C;$$Month#$$Day,#$$Year
.NO FLAGS SUBSTITUTE
.B.PERIOD.FLAG BREAK
.BR.P;
As a guide in designing VAX-|resident software, particularly the VAX-|based
portion of the ACNET network, 
a small project to determine the time requirements of selected VMS system
services has been undertaken.  These times should serve primarily to
select system services used in implementing software not as final and
absolute measures of system service overheads.
.BR.P;The timing loops were obtained on a single machine (the VAX
Software Development System) by a batch job running at priority 14.
The batch job was run in the off-|hours so that minimal interference
from interactive users was encountered.  Some of these timing loops
were run on the Operational VAX at priority 30 or 31.  The results
were similar for both machines.
.BR.P;The timings were all performed from FORTRAN.  This implies a "__G"
form of the call with the argument lists being mostly pre-|stored.
The effect of calling the system services from FORTRAN is a minor
source of error compared to the large variability in the results from
normal VMS operations.  The results listed below are relatively
accurate to about 5 microseconds (all time results are in
^&microseconds\&).
However, by performing multiple runs of the timing programs and from
early tests, there are considerable and very large variances in the
times to perform any system service.  The variations seem to be
enhanced as the system becomes busy with other users and activities.
.BR.P;The times were actually measured with a fairly complicated
technique.  However, a few of the times were measured previously
by the simple method of timing a loop that executes a very large
(10 million or so) number of the system service calls.  The total
time to complete the entire loop divided by the number of loop
gave times in good agreement with those reported here.
The simpler scheme used for the RSX-11M directive timings was
not employed since the KW11-K clocks are not installed on the VAXes.
Instead, a user-|written system service in a privileged shareable image
was constructed.  This system service returned the current contents of
the incremental count register that is part of the standard VAX incremental
timer.  Since this same timer is used by VMS to generate the 10 millisecond
system ticks, the counter could only be read.  A pair of routines were
then written to call this service before and after an instruction sequence
to be timed.  Before reading the initial value of the hardware clock, the
first routine would set a scheduled wakeup with a delta time of 10 milliseconds
and then hibernate (see the $SCHDWK and $HIBER system services).  This would
serve to synchronize the timing programs with the system tick and somewhat
insure that approximately 10 milliseconds were available before the incremental
timer overflowed and triggered the system timer interrupt.  Checks 
were made in the interface routine
to determine if such an overflow had occurred.
The overhead for calling these routines was measured by timing with
no intervening operation. The measured value was approximately
143 microseconds.
.BR.P;The timer routines were imbedded in a FORTRAN timing executive
subroutine that would call an external routine (passed as an argument)
to perform the timing for one operation and return the results.
The timer executive would first time the operation for 100 tries to generate
a guesstimate of the operation's time.  This was done as experiments had
shown that while the distribution of measured times would show a distinct
and narrow peak, there would be a very long tail towards longer times.
The guesstimate then served to define limits (-5 and +25 microseconds from
the guesstimate) used in the calculational loop to determine the average
time to perform the desired operation.  Further checks were made to insure
that 500 good in-|range timings were obtained in determining the average.
The null operation time (see above) has been subtracted from the results
reported below.
.PAGE
.C;Table I
.TAB STOPS 58
.B2.I+5;^&Event Flag Services\&
.B;$CLREF: clear event flag	##81
.B;$SETEF: set event flag	#135
.B;$READEF: read event flags	##87
.B;$WAITFR: wait for a (set) event flag	##83
.B;$WFLAND: wait for logical AND of (set) event flags	##89
.B;$WFLOR: wait for logical OR or (set) event flags	##84
.B2.I+5;^&Miscellaneous Services\&
.B;$GETJPI: return current process id	#250
.B;$CMEXEC: change mode to executive	##99
.B;$SETPRI: set (raise) process priority	#123
.B2.I+5;^&Process Control Services\&
.B;$CANWAK: cancel wakeups (same process)	#152
.BR;##########cancel wakeups (other process)	#175
.B;$WAKE: wakeup (same process)	#106
.BR;########wakeup (other process)	#127
.B;$WAKE+$HIBER: hibernate with pending wakeup	#196
.B;$SUSPND: suspend other process	#234
.B;$RESUME: resume other process	#123
.PAGE
.C;Table I (cont.)
.B2.I+5;^&Time and Timer Services\&
.B;$SCHDWK: schedule wakeups (other process)	#252
.B;$GETTIM: get system time	##76
.B;$NUMTIM: get system time in numeric format	#278
.B;$SETIMR: set event flag at specified time	#278
.BR;##########call AST at specified time	#279
.B;$CANTIM: cancel all timer requests	#265
.BR;##########cancel selected timer request	#285
.B2.I+5;^&AST Services\&
.B;$SETAST: enable/disable AST's	#117
.B;$DCLAST: declare and call an AST	#484
.BR;##########declare AST (delivery disabled)	#201
.B2.I+5;^&User-written Network AST Services\&
.B;USER__SETINA: enable/disable internal network AST	#115
.B;USER__DCLINA: queue network AST for another process	#371
.B;USER__DCLNPA: queue and deliver network process AST	#982
.B2.I+5;^&I/O System Services\&
.B;$QIO: to NLA0:	#813
.BR;#######to NLA0: with AST called	1094
.B;$QIOW: to NLA0:	#871
.PAGE
.C;Table I (cont.)
.B2.I+5;^&Memory Management Services (5 pages affected)\&
.B;$EXPREG: expand P0 region	#408
.B;$CNTREG: contract P0 region	#639
.B;$CRETVA: create specified virtual addresses	#383
.B;$DELTVA: delete specified virtual addresses	#626
.B;$SETPRT: set protection on pages	3690
.B;$MGBLSC: map global section to specified addresses	1839
.BR;##########map global section by extending P0 region	1867
.BR;##########change mapping of specified addresses	2431
.PAGE
.BR.P;The VMS overhead times for mailbox operations have also been measured.
These measurements were done in a manner very similar to that used for
the PCL measurements (see ACNET Design Note No_. 6).  Basically the mailbox
was used between a master and a slave process with messages of varying
length (from 4 bytes up to 10 Kbytes)
being sent from the master to the slave through one mailbox and
then being echoed back by the slave through a separate mailbox.  The timings
were done on the Operational VAX (Single User) and on the Development
VAX (Multi-user) during normal timesharing operations.  Different priorities
were used for the master and slave processes but seemed to have very little
effect on the times (see below).  A separate test was run with the master
process in one VAX and the slave process in the other VAX and the mailboxes
in the MA780 shared memory (the shared memory pool block size was only 128
bytes).
.B2.C;Table III
.TAB STOPS 10,34,45
.B;	Priorities	Overhead	"Bandwidth"
.TAB STOPS 8,19,34,47
.BR;	^&Master\&	^&Slave\&	^&(msec.)\&	^&(Kb/sec)\&
.TAB STOPS 10,20,35,50
.B.C;Single User Results
.B;	30	17	2.796	795
.BR;	17	30	2.745	794
.BR;	30	30	2.770	791
.BR;	#4	#4	2.796	795
.B2.C;Multi-user Results
.B;	14	14	2.941	785
.BR;	#4	#4	2.949	787
.BR;	#2	#2	2.973	787
.B2.C;Shared Memory Results
.B;	30	30	2.393	366
.TEST PAGE 20.B 5
^&Distribution\&
.B.NO PERIOD
##ACNET Design Group
.BR;##I. Gaines    MS 223
.BR;##D. Ritchie     MS 120
.BR;##J. Tinsley
.BR;##file
.B4
fjn: USR$DISK:[NAGY]VAXTIMES.RNO