It can sometimes be useful to set some limits on the number of simultaneous copies of a particular application that alfred will launch. In fact, it can be important to limit the number of copies launched by all alfreds on the network; for example, there may be only a limited number of floating licenses available, or certain applications may put so much stress on the local processor or shared network that it is practical to launch only a few at a time.
Alfred provides a generalized tag and limit mechanism to address these issues. A global tally of tags is kept by the maitre_d, and it will postpone launch requests if a tally has exceeded a maximum defined in the alfred.schedule file.
Tags are taken from several parts of the alfred launch expression: the application name, the service-type search keys, and custom tags. Here's a concrete example to help keep all the jargon straight: recall that Alfred's basic goal is to traverse its structured list of commands and launch as many as it can in parallel; each of these local commands may require suitable remote server to be found before it can be launched. Consider the following command, which could be launched by hand, independent of alfred:
netrender -h somehost my.rib
This will start a process on the local machine (netrender), which
in turn contacts a listening server process (alfserver), on a remote
server machine (somehost).
The locally executing netrender is called the client program with respect to the remote server. It is important to remember that CPU cycles are being consumed on both hosts, for example the netrender client sends RIB and texture files to the remote renderer as well as collecting and formatting the output pixels which are returned; the remote alfserver manages the renderer (prman) which does the actual rendering computations. Some client programs can make use of multiple remote servers; for example several alfservers can be named on the netrender command line and each will work on a portion of the final frame. The command above might be added to an alfred script using the following Cmd (within a Task node):
Cmd {netrender %H my.rib} -service {pixarNRM}
Alfred automatically tallies the application name defined in the
requesting command, and server selection keys which match its bound
server(s). Hence this command will be allowed to launch if the tag tallies
for netrender and pixarNRM are less than the maximum
limits defined in the current schedule. When the command is launched
both counts will be incremented by one, and later decremented when
the command completes.
Commands in an alfred script can also specify additional, arbitrary, tags which are tallied as well, for example:
Cmd {netrender %H my.rib} -service {pixarNRM} -tags {prman}
[...]
Cmd {render my.rib} -tags {prman intensive}
This allows several applications and/or service types to be governed by
a common limit table entry. In this example, two different applications
are being used, only one of which is using a remote server, but the
current tally on the "prman" tag will be checked in both cases. The
second command also adds a tag for "intensive" which might be used
to indicate that the script writer expects this command to incur a
large clienting load; use of this particular tag is described below.
Each limit defined in the schedule has both a local and a global value. Local limits apply individually to each dispatcher, whereas global limits are shared by all dispatchers on the network. One or both of the values may be defined to be "unlimited" by setting the limit to "-1" (negative one). For example, a particular site might know that every artist's desktop system can comfortably client 5 netrenders simultaneously, this would be the local netrender limit; however the global netrender limit could probably remain "unlimited" since netrenders are only launched when there are available servers (that is: the number of alfservers defined in the schedule is already a practical global limit on netrender launches). The current limit settings can be accessed via the "Master Schedule" dialog:
The first column contains the name of the limit entry, case is unimportant. The second column is the global limit allowed for this entry, use -1 to indicate "unlimited". The third column is the local (per-dispatcher) limit. Any subsequent entries on a line are assumed to be per-host exceptions to the local limit value, the format is "hostname:limit"; this mechanism allows a host with unusual capabilities to have special limit values.
Tuning the default limit values requires experience with a site's particular application mix and its processor/network configuration. Given multi-processor systems (and supporting memory etc), the most likely numbers to increase will be the "netrender" clienting limit, and perhaps the "intensive" limit. The impact of simultaneous netrenders on performance can be tricky to predict; the effects of disk and network throughput are crucial, as are RIB-file size and texture map access patterns (client vs server side). The clienting load is limited by other activity on the local host as well, for example on-demand RIB generation; also it is generally a bad idea to client complex parallel netrenders on a host which is also rendering as an alfserver. Users can suppress rendering on their own (clienting) host by deselecting it in the Huntgroup dialog (affects their own jobs), or by running alfred -nimby (affects other user's jobs).
Alfred is often used to launch licensed applications; for example, there are typically a limited number of floating PhotoRealistic-RenderMan licenses available for everyone at a site. In these situations it can be useful to set a global limit which will prevent too many parallel launches of processes which consume a license. The limit table entry used to represent the license count will be site-specific since it requires some knowledge of the applications being launched, and the service keys and tags used in the alfred scripts. Scripts generated by Pixar's MTOR product will always add an "intensive" tag to commands which are likely to create a significant clienting load, and a "prman" tag to commands which are known to consume a PRMan license, so setting the global limit count of "prman" to the license count of the PhotoRealistic-RenderMan feature in the $RMANTREE/etc/license.dat file will prevent alfred from trying to launch too many renderers at the same time. The following example feature line indicates that this site has fifty RenderMan licenses:
FEATURE PhotoRealistic-RenderMan pixard 3.700 31-dec-97
50 ABC01234567890 "Rendomatic Corp"
NOTE: The limit mechanism is specific to alfred; if processes are also being launched via another mechanism then alfred will have no way of knowing about their impact on resource usage. In the special case of PhotoRealistic-RenderMan licenses, if rendering is being done on a remote server and the built-in server ping "Alfping nrm" is being used, then the maitre-d will actively query the license manager to determine if a license is available before launching.
As with the other scheduling data, new limit settings are automatically read from the master schedule file when the file's modification time is newer than alfred's internal version of the data.
|
Pixar Animation Studios
|