Alfred 5.0 - Release Notes
- 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
- 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.
- 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
- 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.
- 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.
- 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.