Remote Device Facilitytm
Previous Contents Index

8.5 Deny Access to Remote Devices

Remote device access can be denied to specific RDCLIENT nodes. This access can also be denied to all remote devices or to specific devices.

8.5.1 Deny Specific RDClients Access to all Remote Devices

To deny all users on a particular node access to all remote devices, add the CLIENT/DENY qualifier before the first device line in the RDSERVER's configuration file.

Example: 


        $ edit tti_rdev:config_zeus.dat 
        CLIENT/DENY=(MINI,BIG)
        DEVICE $1$MUA0:  MUA0, TK50 
        DEVICE MSA0:     TU80, 16700bpi

In the above example, MINI and BIG are the specific RDCLIENT nodes that are denied access to all remote devices (MUA0, TU80) on this RDSERVER (ZEUS) node.

8.5.2 Deny Specific RDClients Access to Specific Remote Devices

To deny all users on a particular node access to a specific remote device, add the /DENY qualifier on the desired device line in the RDSERVER's configuration file.

Example: 


        $ edit tti_rdev:config_zeus.dat 
        DEVICE $1$MUA0:  MUA0, TK50/DENY=(MINI,BIG)
        DEVICE MSA0:     TU80, 16700bpi

In the above example, all users on RDCLIENT nodes MINI and BIG are denied access to remote device MUA0.

8.6 RDserver Inactivity Timer

One of the features of RDF is the RDserver Inactivity Timer. This feature gives system managers more control over rdallocated devices.

The purpose of the RDserver Inactivity Timer is to rddeallocate any rdallocated device if NO I/O activity to the rdallocated device has occurred within a predetermined length of time. When the RDserver Inactivity Timer expires, the server process drops the link to the client node and deallocates the physical device on the server node. On the client side, the client process deallocates the RDEVn0 device.

The default value for the RDserver Inactivity Timer is 3 hours.

The RDserver Inactivity Timer default value can be manually set by defining a system wide logical on the RDserver node prior to rdallocating on the rdclient node. The logical name is RDEV_SERVER_INACTIVITY_TIMEOUT.

To manually set the timeout value: 


        $ DEFINE/SYSTEM RDEV_SERVER_INACTIVITY_TIMEOUT seconds

For example, to set the RDserver Inactivity Timer to 10 hours, you would execute the following command on the RDserver node: 


        $ DEFINE/SYSTEM RDEV_SERVER_INACTIVITY_TIMEOUT 36000

Chapter 9
Network Performance Considerations

Note
The following recomendations are for DECNet Phase IV only. If you are running DECNet/OSI these values are dynamically controlled/changed by DECNet itself and no changes are needed.

9.1 Network Control Program

The Network Control program is used to change various network parameters. The Remote Device Facility (and the rest of your network as a whole) benefits from changing two NCP parameters on all nodes in your network. These parameters are:

9.2 Pipeline Quota

The Pipeline Quota is used to send data packets at an even rate. The number of packet buffers represented by the PIPELINE QUOTA can be calculated as:

BUFFERS = PIPELINE_QUOTA / 1498 (ethernet packet size)

At the default PIPELINE QUOTA of 10000, only six packets may be sent before acknowledgment of a packet from the receiving node is required. The sending node stops after the sixth packet is sent if an acknowledgment is not received.

9.2.1 OpenVMS SERVERS and CLIENTS

We suggest that the PIPELINE QUOTA be changed to 45000 on all OpenVMS nodes. This allows 30 packets to be sent before a packet is acknowledged.

9.2.2 Ultrix CLIENTS

We suggest that the PIPELINE QUOTA be changed from 4096 to 16000 on all Ultrix CLIENT nodes.

9.3 Line Receive Buffers

Similar to the pipeline quota, line receive buffers are used to receive data at a constant rate. The default setting for the number of LINE RECEIVE BUFFERS is six. We suggest that the number of LINE RECEIVE BUFFERS be increased to 30. This allows 30 packets to be received at a time.

9.4 Changing Network Parameters

PIPELINE QUOTA is a NCP Executor parameter. LINE RECEIVE BUFFERS is a NCP Line parameter. The following procedure shows how to display and change these parameters in the permanent DECnet database. These changes should be made on each node of the network.

9.4.1 Changing OpenVMS Network Parameters

The following example shows how to change the PIPELINE QUOTA and LINE RECEIVE BUFFERS network parameters on an OpenVMS system.

Example 9-1 Changing Network Parameters on OpenVMS SERVERS and CLIENTS 

     $ run sys$system:NCP 
     NCP>show executor characteristics 
 
     Node Permanent Characteristics as of 24-JAN-2000 10:10:58 
 
        Executor node = 20.1 (BIG) 
 
        Management version       = V4.0.0 
            . 
            . 
            . 
        Pipeline quota           = 10000 
 
     NCP>define executor pipeline quota 45000 
 
     NCP>show known lines 
     Known line Volatile Summary as of 24-JAN-2000 10:11:13 
       
        Line             State 
 
        SVA-0            on 
 
     NCP>show line sva-0 characteristics 
 
     Line Permanent Characteristics as of 24-JAN-2000 10:11:31 
 
       Line = SVA-0 
 
       Receive buffers          = 6       <-- value to change 
       Controller               = normal 
       Protocol                 = Ethernet 
       Service timer            = 4000 
       Hardware address         = 08-00-2B-0D-D0-5F 
       Device buffer size       = 1498 
 
     NCP>define line sva-0 receive buffers 30 
     NCP>exit

Note
In order for the changed parameters to take effect, the node must be rebooted.

9.4.2 Changing Ultrix Network Parameters

In order to change the PIPELINE QUOTA you must be logged in as ROOT. The following example shows how to change the PIPELINE QUOTA network parameter on an Ultrix CLIENT.

Example 9-2 Changing PIPELINE QUOTA on Ultrix CLIENTS 

     # ncp 
 
     ncp>sho exec chara 
 
     Executor Volatile Characteristics as of Tue Jan 23 14:37:10 PDT 2000 
 
     Executor node =  20.6 (HUEY) 
 
        Identification                     = DECstation 5000/25 
        Management version                 = 4.2.0 
         .
         .
         .
        Pipeline quota                     = 4096  <-- value to change 
         .
         .
         .
     ncp>define exec pipeline quota 16000    
     ncp>set exec state off 
     ncp>set exec state on 
     ncp>exit 
     #

Note
Turning the EXEC STATE OFF removes the node from the network until the SET EXEC STATE ON is performed.

9.5 Resource Considerations

Changing the default values of LINE RECEIVE BUFFERS and PIPELINE QUOTA to the suggested values of 30 and 45000 consumes less than 140 pages of NONPAGED DYNAMIC MEMORY. In addition, the number of Large Request Packets (LRP's) may need to be increased and it is recommended that the NETACP BYTLM be raised from the default value.

9.5.1 Large Request Packets

Note
The LRPCOUNT and LRPCOUNTV SYSGEN parameters only exist in versions 5.x of OpenVMS. These two parameters are not used in OpenVMS versions 6.x or greater. You can skip this section if you are currently running version 6.x or greater.

LRP's are used by DECnet for sending and receiving messages. A minimum of 30 free LRP's is recommended during peak times. The number of LRP's is governed by the SYSGEN parameters LRPCOUNT and LRPCOUNTV. These parameters and the number of free LRP's can be determined by the DCL command: 


  $ SHOW MEMORY/POOL/FULL 
 
              System Memory Resources on 24-JAN-2000 08:13:57.66 
Large Packet (LRP) Lookaside List            Packets       Bytes       
    Current Total Size                            36       59328 
    Initial Size (LRPCOUNT)                       25       41200 
    Maximum Size (LRPCOUNTV)                     200      329600         
    Free Space                                    20       32960

This VAX currently has a total of 36 LRP's. The SYSGEN parameter LRPCOUNT (LRP Count) has been set to 25. So the Current Size is not the same as the LRPCOUNT (the Initial Size). This means that OpenVMS has allocated more LRP's. This causes system performance degradation while OpenVMS is expanding the LRP lookaside list. LRPCOUNT should be raised to AT LEAST 36 so OpenVMS will not have to allocate LRP's.

The minimum recommendation for LRPCOUNT is 50. Since the LRPCOUNT is only 25, the LRPCOUNT would be raised on this machine even if the current size was also 25.

Right now there are 20 free LRP's. This is below the recommended free amount of 30, so this also means that the LRPCOUNT should be raised. Raising the LRPCOUNT to 50 when there are currently 36 LRP's has the effect of adding 14 LRP's. Since 14 plus the 20 free is over 30, there should be over 30 free LRP's after LRPCOUNT is set to 50.

The SYSGEN parameter LRPCOUNTV (LRP Count Virtual) has been set to 200. LRPCOUNTV should be at least four times LRPCOUNT, so raising LRPCOUNT may mean that LRPCOUNTV has to be raised. In this case, since 200 is exactly four times 50 (the new LRPCOUNT value), LRPCOUNTV does not have to be raised.

Changes to LRPCOUNT or LRPCOUNTV should be made in both SYSGEN using CURRENT and in the SYS$SYSTEM:MODPARAMS.DAT file for when AUTOGEN is run with REBOOT.

Example 9-3 Changing LRPCOUNT to 50 in SYSGEN 

 
   Username:  SYSTEM 
   Password:  (the system password) 
 
  $ SET DEFAULT SYS$SYSTEM 
  $ RUN SYSGEN 
  SYSGEN>  USE CURRENT 
  SYSGEN>  SH LRPCOUNT 
  Parameter Name             Current   Default   Minimum   Maximum 
  LRPCOUNT                        25         4         0      4096 
  SYSGEN>  SET LRPCOUNT 50 
  SYSGEN>  WRITE CURRENT 
  SYSGEN>  SH LRPCOUNT 
  Parameter Name             Current   Default   Minimum   Maximum 
  LRPCOUNT                        50         4         0      4096

Note
After making these SYSGEN changes, you need to reboot your system in order for them to take effect.

To change LRPCOUNT for AUTOGEN, we recommend that the following line be added to MODPARAMS.DAT: 


    $ MIN_LRPCOUNT = 50      ! ADDED {the date} {your initials}

This insures that if AUTOGEN is run, your LRPCOUNT will not be set below 50.

9.5.2 NETACP BYTLM

By default NETACP comes up with a BYTLM of 65,535 which, including overhead, is enough for only 25-30 line receive buffers. This default BYTLM may not be enough. We recommend increasing the NETACP BYTLM parameter to 110,000.

The proper way to increase the BYTLM for NETACP on OpenVMS versions 5.5 and above is to define the Digital provided logical NETACP$BUFFER_LIMIT prior to starting DECNET. Use the following commands to do so: 


  $ DEFINE/SYSTEM/NOLOG NETACP$BUFFER_LIMIT 110000 
  $ @SYS$MANAGER:STARTNET.COM

9.6 Controlling RDF's Effect on the Network

By default, RDF tries to perform I/O requests as fast as possible. In some cases this can cause the network to slow down.

To allow more of the network to become available to other processes, the network bandwidth used by RDF can be reduced by defining RDF logicals PRIOR TO an RDALLOCATE.

Note
Reducing the bandwidth used by RDF slows down RDF's data transfers across the network. This causes I/O operations using RDF to take longer!

9.6.1 OpenVMS Clients

If you want to reduce the effect of one particular OpenVMS Client across the network, define the following two RDF logicals on the CLIENT node.

The default values for both of these logicals is zero (0).

Example: 


   $ DEFINE/SYSTEM RDEV_WRITE_GROUP_SIZE  30 
   $ DEFINE/SYSTEM RDEV_WRITE_GROUP_DELAY  1

To further reduce bandwidth, the GROUP_DELAY can be increased to values up to 255. Each increment is a 10ms delay (100 = one second delay).

9.6.2 OpenVMS Servers

If you want to reduce the effect of the Remote Device Facility on a given SERVER node, define the following two RDF logicals on the SERVER node.

The default values for both of these logicals is zero (0).

Example: 


   $ DEFINE/SYSTEM RDEV_READ_GROUP_SIZE  30 
   $ DEFINE/SYSTEM RDEV_READ_GROUP_DELAY  1

To further reduce bandwidth, the GROUP_DELAY can be increased to values up to 255. Each increment is a 10ms delay (100 = one second delay).

Chapter 10
OPCOM RELAY FACILITY

10.1 Enabling OPCOM Messages

The RDF OPCOM RELAY FACILITY is used to relay RDF CLIENT operator requests to other nodes in the network.

This is an example of a standard OpenVMS OPCOM message: 


     %%%%%%%%%%%  OPCOM  19-JAN-2000 17:00:29.04  %%%%%%%%%%% 
     Request 63, from user DJ on FAST 
     Please mount device _MSA0:

Here is an example of an RDF relayed OPCOM message: 


     %%%%%%%%%%%  OPCOM  19-JAN-2000 17:05:29.12  %%%%%%%%%%%    
     (from node TTI  at 19-JAN-2000 17:05:16.50) 
     Request 64, from user SYSTEM on TTI 
     Please mount device TTI$MSA0: on node TTI:: 
      (...from user DJ on node FAST:: via Remote Device Facility)

The OPCOM RELAY FACILITY is enabled when the RDCLIENT_STARTUP procedure is run. It has three modes of operation:

Table 10-1 OPCOM RELAY FACILITY Modes of Operation
Relay Mode Description
CLUSTER Relay RDF OPCOM messages to all operator consoles in a cluster if the message is generated either from an RDCLIENT that is another node in the cluster or from a remote RDCLIENT node, i.e., one that is not a member of the cluster
REMOTE Relay RDF OPCOM messages to all operator consoles in a cluster only if the message is generated from a remote RDCLIENT node
LOCAL Disable the OPCOM RELAY FACILITY

CLUSTER is the default OPCOM relay mode. To enable the LOCAL or REMOTE relay mode, include the appropriate parameter when running the RDCLIENT_STARTUP procedure.

For example: 


     $@tti_rdev:rdclient_startup LOCAL 
 
     $@tti_rdev:rdclient_startup REMOTE

To change the mode of operation without shutting down the RDCLIENT, use the following DCL command before RDALLOCATING a device. 


     $ define/system/exec/nolog rdev_opcom_relay_ctl "option"

where "option" is the desired relay mode, i.e., CLUSTER, REMOTE or LOCAL.

For example: 


     $ define/system/exec/nolog rdev_opcom_relay_ctl LOCAL

Note
If you are running OpenVMS 5.5 and are using TMSCP served tapes, in order to avoid generating both RDF and OpenVMS OPCOM messages, you should use the REMOTE option.

To check if you are using TMSCP served tapes: 


     $ write sys$output f$getsyi("tmscp_load") 
       1

A 1 means tapes can be TMSCP served, a 0 means they cannot.

10.2 System Requirements

The following conditions must be met for the OPCOM RELAY FACILITY to be active.

The version of OpenVMS can be found by: 


     $ write sys$output f$getsyi("VERSION") 
       V5.5

To see if the OPCOM process is running on both the RDCLIENT and RDSERVER nodes: 


     $ show system 
 
     OpenVMS V5.5  on node FAST  11-JAN-2000 16:23:27.15   Uptime  0 05:10:04 
      Pid    Process Name  State  Pri   I/O       CPU       Page flts Ph.Mem 
         .
         .
         .
      2840008C OPCOM        HIB    8    103   0 00:00:00.29     339    189 
         .
         .
         .

Previous Next Contents Index