New Features

• Alfserver status now available in nrmserver-only mode   -   Status information provided by alfserver is now also available even if the process is running in nrmserver-only mode (i.e. when not providing the more general alfserver services, nor consuming an alfserver license). Status is obtained by using a telnet client to connect to port 1501 on the server machine, then type status for basic server information, or help for a list of additional commands.
• Alfserver metrics across subnets   -   A new configuration option allows sites to configure the multicast "hop count" used by the alfserver metrics reporting mechanism. The IP socket configuration option IP_MULTICAST_TTL is used by most routers to decide whether multicast packets should be forwarded between networks or not. Despite being named "time-to-live," almost all routers treat it as a hop-count, rather than as time in seconds. The default value is "1" meaning that the packets should be allowed to leave the local host and enter the local subnet, but are not forwarded across router boundaries. Sites at which the maitre-d and alfservers are on separate subnets (i.e. separated by router), a larger value may be required to allow the metrics packets to be seen by the maitre-d. The configuration variable "MulticastTTL" can be specified in one or more of RAT.ini, alfred.ini, alfserver.ini.

Enhancements

• Alfred maintains a per-job client working directory   -   Before executing local (client) commands for a particular job, the dispatcher now makes an attempt to change directories to the directory which was current when the job was first spooled. This can help in situations in which multiple jobs spooled from different directories are active, and local commands or arguments are not using fully-qualified paths.
• The new pixarIrma service key can now be used to indicate that a server (slot) is capable of running the new Irma rerenderer.
• The default alfserver.ini file now contains more of the options previously controlled by command-line options.
• The maitre-d slot assignment preemption trigger used by the default assigner can now be controlled using an alfred.ini setting. The configuration variable "preemptionTrigger" is queried once when the maitre-d starts. The default value is 100.0
• Override for local domainname   -   The alfred http interface makes use of the local internet domain name when constructing URLs. This name is sometimes not set or inappropriate for alfred usage. A new configuration setting, "localDomain" in alfred.ini allows a site to specify which domain setting should be used in these URLs.
• Job clean-up behavior   -   A new configuration setting "alwaysDoJobCleanup" is available in alfred.ini to control whether job-level cleanup commands are run for jobs that have never been active. If set to '1' (the default) then all job-level cleanup commands will be run when a job is deleted, whether or not the job has been active. This can be important for jobs that need to cleanup auxilliary files that were created when the job was spooled, such as RIB files, frozen copies of models, etc etc. If set to '0', then the cleanups only run when a job has been active, which is sensible only if the temporary files used by jobs are created by the jobs themselves.
• Interpretation of Local Limit Counts   -   The configuration setting "policyLocalLimits" can be used to determine how "local limit" counts are interpreted. The available settings are location or owner. The default setting (location) means that the local limit count defines an upper limit on the number of processes of a certain type which can be run on the local system simultaneously. For example, if stand-alone MTOR is being used to generate RIB locally, then only a small number of these processes should run at the same time since they consume a lot of memory and CPU for large Maya scenes.

  However, an alternate interpretation is also available. The setting "owner" means that the count should be used to limit commands of a certain type, including remotely executing commands, which originate from the same dispatcher. This setting provides a way of creating a policy that enforces the idea that no one can consume more than a given number of licenses, for example, independent of whether their processes are executing on their own machine or somewhere else on the network.

Bug Fixes

• User-ids containing spaces would cause the alfred dispatcher and UI to fail to connect properly. This situation is rare on unix systems, but can happen on Windows. The problem has been addressed in this release, but administrators should be aware that one-word userids will simplify other aspects of interoperation between Windows and unix, such as remote execution authentication, etc.
• Long crew-name lists in the schedule definition would sometimes cause the maitre-d to crash. This has been fixed.
• Boot-time launch of Alfred via init.d scripts was sometimes causing alfred to crash. The maitre-d is often launched at boot-time in this fashion. A logging bug related to the init.d user environment has been fixed.
• Alfserver on some Windows 2000 systems could cause various Control Panels to wedge or respond slowly until alfserver was stopped. This has been fixed.
• On some newer models of SGI Irix systems, Alfserver would sometimes crash when handling its first netrender request. This has been fixed.

Known Problems

• An undiagnosed problem on some Win32 systems using gigabit ethernet cards can sometimes cause the system to "bluescreen" or to be knocked off the network when netrender jobs are sent to these hosts. The problem seems to be specific to certain models of gigabit cards and is triggered when the remote prman process begins i/o over the netrender socket to the client host. Netrendering "locally" on these systems works correctly.