[an error occurred while processing this directive]

HP OpenVMS Systems

ask the wizard
Content starts here

erratic DECnet task-to-task response times?

» close window

The Question is:

 
I have a program that acts as a service for
another program.  Both programs run as detached
processes.  I get requests via a mailbox to
read a record from a file.  My program has up to 500 files open.  I retrieve
the data from
the appropriate file and return it to the other
process.  Most of the program is designed to be
AST driven.  That is, we do asynchronous RMS
GETs with AST routines and we use the mailbox
data notification AST.
 
I am trying to add support for acting as a
middleman between the other processes and a
process on another VAX.  We have DECnet Phase
IV.  I use non-transparent task-to-task
communications.  I have no problem creating a
logical link to the process on the other VAX.
My problem is that sometimes the response from
the other VAX is delayed sometimes for 20
seconds (at other times the response is nearly
immediate <1sec).  The process on the other VAX
seems to receive the request in a timely manner
and returns it in less than a second.  I cannot
use a $QIOW since that would interfere with
processing the other ASTs.  All the examples I
have seen use $QIOWs.  The DTS/DTR utilities
report the ability to do >100 messages/sec at
16 bytes per message.  I have added code to my
program to generate test requests and encounter
this problem when I do 1 request every 5
seconds or faster.  What is the problem with
non-transparent task-to-task communications and
the $QIO routine?
 
 
 


The Answer is :

 
  There are many potential causes, ranging from (potential) application
  bugs to (potential) DECnet bugs to networking problems or congestion.
 
  The Wizard would suggest integrating support for debugging within the
  application, including timestamp information on the transmission and
  reception of messages at the DECnet routines.  (Exchanging information
  on the protocol version, the remote system name, and the remote system
  time -- as compared to the local system time -- during the initial
  network connection negotiations -- can help isolate the current clock
  skew value.  And this can make comparing the traffic logs on two systems
  rather easier.)
 
  The Wizard would also suggest looking for process quota limitations on
  both ends of the connection, with particular interest in this case on
  ensuring that the sender's quotas are sufficient for all outstanding
  I/O activity.
 
  The Wizard will assume that DECnet connections are not being started
  and shut down frequently, that the connections are being maintained
  for a series of messages.
 
  If this information is insufficient or does not lead to a solution,
  please contact the customer support center.
 

answer written or last revised on ( 3-SEP-1998 )

» close window