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"/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
