Enter your search terms Submit search form
	Web pdp-10.trailing-edge.com

                         DTR/DTS User's Guide



1.0  INTRODUCTION

     This pair of programs is used to test the TOPS-20  implementation
of   the  NSP  protocol.   DTR  and  DTS  were  used  to  perform  the
certification between TOPS-20 and all other DECnet implementations  to
which it may be connected.

     In the field, DTR and DTS may be used as a check  that  the  link
between  two  systems  is functioning on the user level.  DTS can also
generate throughput figures which can be used to  determine  how  much
data can be transferred over the link per unit time.

     Before using  these  two  programs,  it  is  important  that  the
specialist  understand  the concept of source and target tasks and the
types of messages which may be sent at user  level.   This  implies  a
general  (not  necessarily bit-level) understanding of chapters 3-5 of
the TOPS-20 DECnet-20 Programmer's Guide and Operations Manual,  order
number AA-5091B-TM.



2.0  GENERAL OPERATING INSTRUCTIONS

     Before testing can start, both DTR and DTS should be running.

     DTR runs as a DECnet server on the remote side of the  link.   It
is  generally  started  first  and  is then allowed to run undisturbed
until testing is done, since it requires no  attention  once  started.
If the remote system is another -20, the DTR from this SWSkit is used.
Otherwise, the version of DTR appropriate for the remote node is used.
(Versions of DTR and DTS have been written for all DECnet systems.)

     Once DTR is started, DTS is run on the local side of the link (in
this  case,  on the -20 system).  Any of several kinds of tests may be
run depending on user commands.

     Both DTR and DTS must be run with WHEEL  or  OPERATOR  privileges
enabled.  This is because both programs use DECnet object type 63, and
any use of a non-zero object type requires privileges.   DTR  and  DTS
may  be  run  simultaneously  with  other  DECnet  applications  on  a
timesharing system.  A stand-alone machine is not required.



3.0  DTR COMMANDS

     DTR  has  the  same  command  set  as   DYNETS,   so   see   file
DYNETS-USER-MANUAL.MEM for more information.  (In fact, the DTR prompt
is DYNETS>.) Generally the only command used is the  DECLARE  command.
This sets up a server task to which DTS will communicate.  The command
to use is:

                    DECLARE 63.DTR/BYTE:8/RECL:255

This sets up a server name with object type 63, and specifies the byte
size and the maximum record size to be used on the link.

     File DTR.CTL may be submitted as a batch job to start up DTR with
four such tasks.  This will enable DTR to talk to up to four copies of
DTS.  The WAIT command at the end of the  control  file  prevents  DTR
from  going  into input wait.  This allows it to run indefinitly after
the last command has been entered, without  being  stopped  by  BATCON
because  there are no more commands in the control file.  When testing
is done, the batch job can be killed with the EXEC's CANCEL command.

     DTR may also be started manually by typing the DECLARE command by
hand.   If  DTR  is run on a timesharing terminal, the WAIT command is
optional.



4.0  DTS COMMANDS

     This is the command syntax for DTS, as taken from DTS.HLP.


DTS>HELP (WITH DTS)

DTS>TAKE (COMMANDS FROM) command_file (LOGGING OUTPUT ON) log_file

DTS>TEST node_name /TEST:CONNECT|DATA|DISCONNECT|INTERRUPT
                   /PRINT:YES|NO

DTS>WAIT (AND DON'T PROMPT)

DTS>EXIT (TO MONITOR)

     Subcommands to TEST command are:

CONNECT_TEST>ACCEPT|REJECT /DATA:STANDARD|NONE|RECEIVED

DISCONNECT_TEST>DISCONNECT|ABORT /DATA:STANDARD|NONE|RECEIVED

DATA_TEST>SINK|SEQUENCE|PATTERN|ECHO /MSG:nnn /BUFS:nnn 
          /TIME:hh:mm:ss /BAUD:nnnnn /NAK:NONE|RANDOM|nnn 
          /BPC:NONE|RANDOM|nnn /NO-FLOW-CONTROL 
          /MESSAGE-FLOW-CONTROL:nnn /SEGMENT-FLOW-CONTROL:nnn

INTERRUPT_TEST>SINK|SEQUENCE|PATTERN|ECHO /TIME:hh:mm:ss
               /MSG:nnn /FLOW:nnn


     The function of the HELP,  TAKE,  and  EXIT  commands  should  be
obvious.

     The TEST command is the main command of the program.   The  /TEST
switch controls which of four tests will be done:

     1.  CONNECT  --  tests  accepted  and   rejected   logical   link
         connections

     2.  DATA -- tests regular data transfer and  calculates  transfer
         rates

     3.  DISCONNECT -- tests synchronous and aborted link disconnects

     4.  INTERRUPT -- tests interrupt data transfer


     The /PRINT switch controls whether or not informational and error
messages are typed by the remote DTR.  Much of the same information is
typed out by the DTS running locally.



4.1  CONNECT Test Options

     You can specify whether or not  the  connect  request  is  to  be
accepted or rejected by DTR.  The /DATA switch controls whether or not
optional user data is returned with  the  connect  accept  or  reject.
/DATA:NONE  specifies  no user data, /DATA:STANDARD specifies 16 bytes
of data (the first sixteen letters of  the  alphabet  in  ASCII),  and
/DATA:RECEIVED  specifies  that  the  data received from the sender is
used as the data for the response.  The data  is  not  typed  out  and
there  is no way to specify your choice of data, but the three options
try out various features in the protocol.



4.2  DISCONNECT Test Options

     The disconnect request may be either a normal disconnect  (option
DISCONNECT)  or an ABORT (option ABORT).  The DATA switch has the same
meaning as it does for the CONNECT test.



4.3  DATA Test Options

     There are four kinds of DATA tests.

     1.  SINK test -- The receiving DTR task makes no  checks  on  the
         data.  It simply reads it and throws it away.

     2.  SEQUENCE test -- Each message contains a  four-byte  sequence
         number which is checked by DTR.  If a message is received out
         of order, the link is aborted.

     3.  PATTERN test -- Each message contains a sequence  number,  as
         for  the  SEQUENCE  test,  plus  a  byte for a pattern.  (The
         pattern cycles through the ASCII characters of A-Z and  0-9.)
         If an error is detected, the link is aborted.

     4.  ECHO test -- Data messages received by DTR  are  returned  to
         DTS.   There is no pattern or sequence checking.  This is the
         only option in which data messages are being  transmitted  in
         both directions at once.


     There are many switches for the DATA test.  Only a few are really
useful.

     /MSG:nnn is used to specify the size of the data  message  to  be
sent.  The size must not be larger than the maximum you specified when
DTR was started.  The minimum size is 1 for the SINK test, 4  for  the
SEQUENCE  test, and 5 for the PATTERN and ECHO tests.  The size of the
message affects performance, so it can  be  interesting  to  vary  the
value to see the effects on the rate of transfer over the line.

     /BUFS:nnn is used to specify the number of send  buffers.   Leave
this  at  the  default  value  of  1  since  multiple  buffers are not
supported.

     /TIME:hh:mm:ss is the length of time for which the test is to  be
performed.  The maximum is not known for the -20 but many of the other
DTR/DTS implementations have a documented limit of 18 hours.  Most  of
the in-house tests are performed for only a few minutes.  (The default
is two minutes.)

     /BAUD:nnnnn is the baud rate of the communications line.  If  you
specify  a  baud  rate,  DTS will calculate the efficiency of the line
when the test is finished.  Between this and the data transfer rate in
bits  per second which is always supplied, you should be able to get a
general idea of how much data you can transfer over the line.  Be sure
to read the notes on performance later on in this memo, however.

     /NAK:options was intended to give  the  user  the  capability  to
generate  NAKs  to messages every n messages, or randomly.  It has not
been fully implemented, so leave this switch alone.

     /BPC:options stands  for  back-pressure.   Back-pressure  is  the
ability of the receiver to request the sender to stop sending data for
some length of time.  This is not fully implemented either, so  ignore
this.

     The rest of  the  switches  handle  flow-control  options  which,
again,  have not been fully implemented.  /SEGMENT-FLOW-CONTROL:8 must
be  specified  for  the  first  data  test.   Aside  from  this,   the
flow-control  switches  should  be left alone.  In very general terms,
flow control is the ability for a sender to have more  than  one  data
message in transit to the receiver.



4.4  INTERRUPT Test Options

     The interrupt test has the same four kinds of tests as  the  data
test -- SINK, SEQUENCE, PATTERN, and ECHO.  The meanings are the same.
The /TIME and /MSG switches have the same meanings that  they  do  for
the  data  test.  The /MSG switch for this test has a maximum value of
16.  The /FLOW switch has to do with flow control and, as for the data
test, should be ignored.



4.5  Default Handling

     The initial defaults for DTS are listed  below.   These  defaults
are  continually  updated  to match the last value you specified.  For
example, if you specify /TIME:0:5:0 in a DATA test, the default  value
for  the time switch is changed to be five minutes until you change it
again.

Defaults for TEST command

       DTS>TEST local-node /TEST:DATA /PRINT:YES

Defaults for subcommands

       CONNECT_TEST>ACCEPT /DATA:NONE

       DISCONNECT_TEST>DISCONNECT /DATA:NONE

       DATA_TEST>SINK /MSG:192 /BUFS:1 /TIME:0:2:0 /BAUD:0 /NAK:NONE
           /BPC:NONE /MESSAGE-FLOW-CONTROL:2 /SEGMENT-FLOW-CONTROL:1

       INTERRUPT_TEST>SINK /TIME:0:2:0 /MSG:16 /FLOW:1



5.0  NOTES ON PERFORMANCE FIGURES

     When the data test concludes, figures on the number of bytes  per
second transferred are printed.  In addition, if a value was specified
for the /BAUD switch, the efficiency of the  line  is  printed.   Some
discretion  is  necessary in the use of these figures.  The figure for
the amount of data which is used in the calculation includes both sent
and  received  data.  Since the line is full duplex, sent and received
data can be transferred simultaneously.  This makes  it  theoretically
possible  to  see  a  efficiency of greater than 100 percent.  For the
SINK, SEQUENCE, and PATTERN tests, this is not a problem,  since  data
is  only sent by DTS, and no data is received.  However, when the ECHO
test is performed, the efficiency figures are higher because  messages
are being sent in both directions at the same time.

     If you are interested in finding out, for example, how quickly  a
file  can be transferred over the link, the figures from the ECHO test
will be too optimistic.  Use one of the other tests in which  data  is
transferred only in one direction.

     The message size (/MSG switch) affects the rate of data transfer.
The efficiency data will be misleading if the message size you specify
for  DTS  differs  from  the  message  size  which  is  used  by  your
application.

     Naturally, the accuracy  of  the  figures  is  dependent  on  the
correct specification of the /BAUD switch.  If you specify a baud rate
of 4800 and the line is  actually  running  at  9600,  the  efficiency
figures will look much better than they actually are.



6.0  EXAMPLES

     DTR.CTL is a control file which will start up DTR,  as  mentioned
above.

     DTS-EXAMPLE.CMD is  a  command  file  which  will  exercise  most
varieties  of  the  DTS  CONNECT,  DISCONNECT,  and  INTERRUPT  tests.
Comments at the beginning of the file indicate how it must be modified
for your own configuration.

     DTS-DATA-EXAMPLE.CMD is a DTS command file which does a SINK DATA
test and generates efficiency figures for the line.