TOC, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14

11) NTSNET


11.1) How does ntsnet find the local executable?

The ntsnet command line must always specify a Linda command name. This command name can optionally be prefixed with a directory specification. If it is, then the executable must be in the specified directory. Otherwise, ntsnet uses the TSNET_PATH environment variable to find executable. When searching for the executable, ntsnet appends the suffix string (if used) to the command name.

For example, if the local node uses the suffix string ".sparc", then the command

 

  d /tmp
		  tsnet ./suite


will cause ntsnet to look for the file "/tmp/suite.sparc". If it doesn't exist, ntsnet will print an error message.

 

  etenv TSNET_PATH /usr/bin/linda:.
		  d /tmp
		  tsnet suite


In this case, ntsnet will first look for "/usr/bin/linda/suite.sparc", and if it is not there, it will look for "/tmp/suite.sparc".

Note that if TSNET_PATH is not defined, ntsnet uses a default value of "/usr/bin/linda:.". So in this case, the setenv command is not necessary, but is used for clarity.

Also, note that the rexecdir resource and the -p option have no effect where ntsnet looks for the local executable.


11.2) How does ntsnet find executables to distribute?

If distribution is enabled, they must be in the same directory as the local executable. They must have the appropriate suffix string.

If your local machine is a Sparc, but you also run on have RS/6000s and HP9000s,

 

  etenv TSNET_PATH /usr/bin/linda:.
		  d /tmp
		   /usr/bin/linda
		  suite.hp9000 suite.rs6000 suite.sparc
		  tsnet -d suite


Ntsnet finds the local executable in /usr/bin/linda, and then looks in the same directory for the files "suite.hp9000" and "suite.rs6000". It will copy "/usr/bin/linda/suite.hp9000" to the appropriate directory on all nodes that use the ".hp9000" suffix string, and "/usr/bin/linda/suite.rs6000" to the appropriate directory on all nodes that use the ".rs6000" suffix string.


11.3) To what directory does ntsnet copy executables on remote machines?

If the -d option is used, ntsnet will distribute an executable to each remote node at the beginning of the run and remove them at the end. Ntsnet normally uses the rexecdir resource in the configuration file to determine where to copy an executable. The default and recommended value of rexecdir is "Parallel". This means that ntsnet copies the executable to the remote directory that is "parallel" (or equivalent) to the local executable directory. This parallel directory is determined by using the ntsnet map file to translate the name of the local executable directory. Very often, no translation is needed, so for the previous example, ntsnet would copy the executables to /usr/bin/linda on the remote machines. The map files are helpful if different nodes have dissimilar directory structures.

If rexecdir is set to something other than "Parallel", it must be the name of a directory on the remote machine. Ntsnet will copy the executable to that directory. The rexecdir resource is node specific, so it can be set to a different directory for each node. This provides a simpler, though less powerful, mechanism for copying executables to different directories on different nodes than the use of map files. It is also useful if you want to set up one directory on each remote node that will contain all executables. For example,

 

  d ~/work
		  tsnet -d -opt 'ntsnet.suite.Node.rexecdir: /tmp' /usr/bin/linda/suite


Ntsnet finds suite.sparc in /usr/bin/linda, and then copies "/usr/bin/linda/suite.hp9000" to "/tmp/suite.hp9000" on every node that has the ".hp9000" suffix string.

If the -p option is used, the rexecdir resource is ignored. The executable is copied to the directory that is parallel to the specified directory. So for the command

  tsnet -d -p /tmp /usr/bin/linda/suite


ntsnet
will copy "/usr/bin/linda/suite.hp9000" to "/tmp/suite.hp9000", assuming that a map file doesn't cause any translation. (This can be assured by the use of the +translate option to turn off path translation.) Note that the -p option also sets the remote working directory and is provided primarily for compatibility with the previous tsnet utility. It is not recommended for normal use, but can be useful when there isn't a good map file set up for your network.

Note that with the previous tsnet utility, it was very common to use the command

  % tsnet -p $cwd suite


when working in a directory that can be accessed via NFS by all nodes in an homogeneous network. The -p option is not needed for this case with ntsnet. This example only worked with tsnet if "$cwd" evaluated to a directory name that all remote nodes understood, and suite was in that directory. With ntsnet, if suite is in the current working directory, you can use the command

  tsnet suite


and, by default, ntsnet will expect suite to be in the directory of the same name on the remote nodes.


11.4) In what directory does ntsnet expect to find executables if they are not distributed?

Ntsnet uses exactly the same mechanism as for determining where to copy them.

For example,

  etenv TSNET_PATH /usr/bin/linda:.
		  d /tmp
		   /usr/bin/linda
		  suite.sparc
		  % rsh myhp9000 ls /usr/bin/linda
		  suite.hp9000
		  % rsh myrs6000 ls /usr/bin/linda
		  suite.rs6000
		  tsnet -nodelist "myhp9000 myrs6000" suite


will result in ntsnet executing "/usr/bin/linda/suite.sparc" on the local node, "/usr/bin/linda/suite.hp9000" on myhp9000, and "/usr/bin/linda/suite.rs6000" on myrs6000.

A map file can be used to map "/usr/bin/linda" to a different name. If suite.hp9000 was installed in "/usr/homes/frank/linda" on myhp9000, a map file such as

  map /usr/bin/linda {
		   myhp9000 : /usr/homes/frank/linda;
		  }


would tell ntsnet that /usr/homes/frank/linda on myhp9000 is equivalent to /usr/bin/linda on all other nodes.


11.5) What directory does ntsnet use as the working directory for the local Linda process?

Ntsnet always uses the user's current working directory as the working directory for the local Linda process. The rworkdir resource and the -p option have no effect on the local process.


11.6) What directory does ntsnet use as the working directory for the remote Linda processes?

Ntsnet uses a mechanism very similar to the mechanism used for determining the remote executable directory. Ntsnet normally uses the rworkdir resource in the configuration file to determine the remote working directory. The default and recommended value of rworkdir is "Parallel". This means that ntsnet uses the map file to translate the local working directory for each remote node. For example,

 

  d /usr/homes/frank
		  tsnet suite


will cause ntsnet to use the working directory "/usr/homes/frank" on all the remote nodes.

If rworkdir is set to something other than "Parallel", it must be the name of a directory on the remote machine. Ntsnet will use that directory as the remote working directory. The rworkdir resource is node specific, so it can be set to a different directory for each node. The commands

 

  d /usr/homes/frank
		  tsnet -opt 'ntsnet.suite.Node.rworkdir: /tmp' ./suite


will cause ntsnet to use "/tmp" as the working directory on all remote nodes, while the executable will be expected in /usr/homes/frank on all nodes.

If the -p option is used, the rworkdir resource is ignored. The working directory is set to the directory that is parallel to specified directory. So for the example

  
		  tsnet -d -p /tmp suite


ntsnet will use "/tmp" as the working directory on all remote nodes, assuming that a map file doesn't cause any translation.


11.7) What are some map file examples?

If the map file contains the entry

  mapto /net/mynode {
		   mynode : / ;
		  }


and the commands

  d /usr/homes/frank
		  tsnet ./suite


are executed, ntsnet will translate the directory "/usr/homes/frank" to "/net/mynode/usr/homes/frank" on all remote nodes, which is useful if automounting is available.

If the Linda executable is installed in "/usr/bin/linda" on each node, then the map file should also include the entry

  mapto /usr/bin {
		   mynode : /usr/bin;
		  }


For example,

 

  etenv TSNET_PATH /usr/bin/linda:.
		  d /usr/homes/frank
		  tsnet suite


Ntsnet will then use "/net/mynode/usr/homes/frank" for the remote working directory, but "/usr/bin/linda" for the remote executables. This works because the second map entry takes precedence over the first.


11.8) How does ntsnet determine what nodes to run on?

First, ntsnet schedules the master process to run on the local node. Then it makes a list of all nodes that are available to run Linda processes on, and schedules maxworker worker processes to run on those nodes. The local node is always included in the list of available nodes. The scheduling procedure can take into account the load average of each of the nodes, the relative cpu speeds, and other factors as specified in the configuration database. As a result, several processes may be scheduled on one node, while another node is unused.

Ntsnet uses the nodelist resource for determining the list of nodes that are available. This can be done as simply as

  tsnet -n :2 -nodelist "mynode myhp9000 myrs6000" suite


since the -nodelist option can be used to override the nodelist resource. This gives ntsnet a total of three nodes to use (since the local node is mynode). Ntsnet will attempt to schedule two workers (as specified by the -n option) in addition to the master process.

 



TOC, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14

 
Copyright © 2006 Scientific Computing Associates, Inc.