Distributed Processing allows the cell calculations involved in a batch run to be shared over multiple processor cores. Because the calculations are being shared, the amount of time required to process a batch job is significantly reduced. For a more complete description of Distributed Processing, refer to the "Complete Guide to Distributed Processing" (Internet Connection Required).
There are 2 ways to use Distributed Processing: Use Standard Distributed Processing and use AXIS GridLink Module.
Standard Distributed Processing
This is the most common way that Distributed Processing is used. The user sets up the System Parameters to configure AXIS to automatically launch local helpers at the beginning of a batch job. The helpers will help this master only and will be closed at the end.
The following are options for Standard Distributed Processing:
Helpers allowed - Standard Distributed Processing allows a maximum of 15 helpers in the same computer. The user can, therefore, set the maximum number of helpers to any number between 1 and 15.
Auto-start local helpers - select this option to invoke some local helpers automatically on a multi-processor machine at the start of any batch job or batch macro and close them at the end. The user can either specify the number of helpers that need to be started, or let AXIS decide it according to the number of CPU cores of the machine. e.g. if the machine has 4 CPU cores, the master will invoke 4 - 1 = 3 local helpers automatically.
The user can click the button "Advanced Settings" to access the following options:
![]()
Support helpers on other subnets
This option is used for the case that Distributed Processing spans multiple computers. Please note that, starting from AXIS 12.5.03.001, the ability of Standard Distributed Processing to work over multiple computers will be disabled. You will still be able to use distributed processing with up to 15 local automatic helpers in one computer. If you are already using Distributed Processing over multiple machines, we will continue to support your setup for just over a year to allow for a transition to a single box solution. For versions starting with 12.5.03.001 you will need to request a custom code from GGY to enable this part of the functionality. We will be happy to discuss in more detail how your farm is set up and suggest the most appropriate long term solutions over the next year. The "Standard Distributed Processing Spanning Multiple Machines" feature will be completely removed from the system in the February release in 2011.
For more information please refer to the following KB:
http://server1/internal/kbase/kbdetails.asp?searchterm=&articleid=1066Log the number of helpers participating in the distributed processing - to offer users more information in case they need to analyze the run-time.
Automatically detect Windows Firewall status (on XP SP2 only) - Computers might be protected by Windows Firewall, which blocks some communication required to manage Distributed Processing feature of AXIS. It is recommended to turn on this option. When Distributed Processing is used on a Windows XP SP2 machine, AXIS (either a master or a helper) can automatically detect whether it is blocked by Windows Firewall. If it is, it will ask the user if he/her wish to unblock it.
Please note that the local Administrator's right is required to unblock AXIS.
AXIS uses Microsoft Windows Firewall APIs to detect the firewall status. We have discovered that when Group Policy is applied to a machine, the APIs might not report the firewall status correctly. Microsoft has confirmed that this is due to their design limitation. In this case, the user should turn off this option and leave the firewall status management to the operating system.
Log Master/Helper activities - Distributed Processing can log the activities of master and helper computers (which machine joined the processing at what time, etc).
Include cell processing history - this option is only available when the user has selected to log master/helper activities. It will include information on which helper processed each cell in the log file.
Please note that the Master/Helper activities log messages are not saved in System Log, and they will not be logged when a batch is running in a Batch Macro or submitted to GridLink module to run remotely.
Failure Detection Time-out period - A helper that has stopped responding for a certain time period is deemed to have failed. The default value of the time-out period is 1 minute. The user may want to use a longer period if he/she has slow machines. It can be adjusted from 1 to 10 minutes.
Failure Recovery ensures that the master will recover cells that this failed helper has taken but not finished and will redistribute these cells to other machines. Please note that Failure Recovery is not supported in Batch Generate.
The user can click the button "Network Settings" to access the following options:
![]()
Exclude IP Addresses - Suppose that the computer where the AXIS master is running has 2 network cards for 2 separate sub-nets, and all helpers are running on the same sub-net, then the network card on the master computer for the other sub-net will not be used to connect to any helper computer participating the distributed processing. Same situation also applies to a helper computer with more than one network card. However, IP addresses of these unused network cards are still exposed to other computers during the distributed processing. Therefore, one computer may try to connect to an IP address on a different sub-net and will report an error message after the attempt fails. When this happens, a helper will take longer time to join the distributed processing than it should.
The user can specify the IP addresses associated with these unused network cards to make the distributed processing more efficient. The user can either add a new address into this list or remove one from it.
Network Services - the network services settings (UDP Ports, IPX Sockets, TCP port, etc) should not be changed unless they conflict with existing network services. If it becomes necessary to change these settings, please ensure that all masters and helpers that will perform distributed processing together have the same UDP/IPX/NetBIOS settings, and all GridLink Controllers have the same TCP port. Otherwise, they will not be able to communicate with each other.
Standard Distributed Processing can satisfy users for relatively small scale Distributed Processing jobs. e.g. with less than 15 helpers involved in the job. When a dedicated server farm with 64 CPU cores is set up with more than one AXIS version installed and many users use it for their testing and production runs, it becomes impractical to manually control such amount of helpers and to efficiently schedule the farm to meet all users' demands. In some organizations, end users are not granted the permission to log on to servers directly due to security and management reasons.
AXIS GridLink Module makes it easier to manage batch jobs on a server farm. With AXIS GridLink Controller running on the server machine, the user can submit batch jobs to a server machine, and monitor the status of the remote jobs from the local machine without logging on to the server. The controllers will start helpers on server machines automatically once a job is started, and these helpers will be closed automatically once the job is done.
For more information about the AXIS GridLink Module, please refer to the help topic "AXIS GridLink Module". Please note that this feature is available only if the user has the AXIS GridLink Module Licence. Please contact GGY for further assistance.
Computers with Licenced GridLink Controllers - The user needs to specify the name of the server machine where GridLink Controller runs. If the user has more than one licenced GridLink Controller in the list, when user submits a job or wants to monitor the status of a remotely running job, he/she will be asked to select one GridLink Controller from the list.
A default TCP port number is pre-selected through which the local machine will be connecting to GridLink Controller. This number should be used unless it conflicts with an existing network service. When it is necessary, the user can specify the TCP port number in Network Settings dialog. This must be the same port number that is specified in GridLink Controller.
The user can click the button "More Settings" to access the following options:
![]()
Log the number of helpers participating in the distributed processing - to offer users more information in case they need to analyze the run-time.
Automatically detect Windows Firewall status (on XP SP2 only) - Computers might be protected by Windows Firewall, which blocks some communication required to manage Distributed Processing feature of AXIS. It is recommended to turn on this option. When Distributed Processing is used on a Windows XP SP2 machine, AXIS (either a master or a helper) can automatically detect whether it is blocked by Windows Firewall. If it is, it will ask the user if he/her wish to unblock it.
Please note that the local Administrator's right is required to unblock AXIS.
AXIS uses Microsoft Windows Firewall APIs to detect the firewall status. We have discovered that when Group Policy is applied to a machine, the APIs might not report the firewall status correctly. Microsoft has confirmed that this is due to their design limitation. In this case, the user should turn off this option and leave the firewall status management to the operating system.
Network Services - This is the TCP port that AXIS uses to connect to GridLink controllers. You only need to change it when you have changed this number on all GridLink Controllers.
You may have noticed that this dialog has much less parameters
than "Advanced Settings" and "Network Settings" dialogs. This is
because when you are using "GridLink Module", many System
Parameters are farm-specific and managed by GridLink utility,
instead of by AXIS.