Distributed Processing allows the cell calculations involved in a batch run to be shared over multiple computers. 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).
Distributed Processing uses "Windows Sockets 2.0" to communicate between the master and helper computers. All recent versions of Windows have Windows Sockets 2.0 built in, but Windows 95 users need to install the "Windows Socket 2 Update for Windows 95" before using Direct Communication mode distributed processing. This update is included in the AXIS library files and is also available from Microsoft's website. If this update is not installed, Distributed Processing will be disabled in Windows 95.
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. After preparing a batch job, the user run the batch on his/her locally computer, with some helpers manually started on other computers in the organization. Helpers will join the master on the batch job. After the job is done, helpers will still stay, waiting for helping other distributed batch jobs until they are manually closed by the user.
The following are options for Standard Distributed Processing:
Helpers allowed - Standard Distributed Processing allows a maximum of 15 helpers per dataset. 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.
Local helper is a special mode for helper - starts minimized - dynamically points to whatever path the master that invoked it is pointing to, and does not help any process from any other master than the one that invoked it.
The user can click the button "Advanced Settings" to access the following options:
Support helpers on other subnets - the user needs to select this option on the master machine in order to invite helpers sitting on other subnets to join the distributed processing.
Also on the helper machine, the user needs to select "Also help masters on other subnets" option on the dialog that comes up when the user starts the helper from the dataset list dialog, or use a new option "-O" if the user starts the helper from the command line.
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.
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.
