![]() |
|||
![]() |
![]() ![]() |
![]() |
![]() ![]() |
![]() |
![]() ![]() |
![]() |
| ||||||||
qtcsh UsageThe invocation of qtcsh is exactly the same as for tcsh. qtcsh extends tcsh in providing support for the .qtask file and by offering a set of specialized shell built-in modes. The .qtask file is defined as follows. Each line in the file has the following format:
The optional leading exclamation mark (!) defines the precedence between conflicting definitions in a global cluster .qtask file and the personal .qtask file of the qtcsh user. If the exclamation mark is missing in the global cluster file, a conflicting definition in the user file overrides the definition in the global cluster file. If the exclamation mark is in the global cluster file, the corresponding definition cannot be overridden. app-name specifies the name of the application that, when typed on a command line in a qtcsh, is submitted to the grid engine system for remote execution. qrsh-options specifies the options to the qrsh facility to use. These options define resource requirements for the application. The application name must appear in the command line exactly as the application is defined in the .qtask file. If the application name is prefixed with a path name, a local binary is addressed. No remote execution is intended. csh aliases are expanded before a comparison with the application names is performed. The applications intended for remote execution can also appear anywhere in a qtcsh command line, in particular before or after standard I/O redirections. Hence, the following examples are valid and meaningful syntax:
Given this .qtask file, the following qtcsh command lines:
implicitly result in:
qtcsh can operate in different modes, influenced by switches that can be on or off:
The setting of these modes can be changed using option arguments of qtcsh at start time or with the shell built-in command qrshmode at runtime. See the qtcsh(1) man page for more information. Parallel Makefile Processing With qmakeqmake is a replacement for the standard UNIX make facility. qmake extends make by its ability to distribute independent make steps across a cluster of suitable machines. qmake is built around the popular GNU-make facility gmake. See the information that is provided in sge-root/3rd_party for details on the involvement of gmake. To ensure that a distributed make process can run to completion, qmake first allocates the required resources in a way analogous to a parallel job. qmake then manages this set of resources without further interaction with the scheduling. qmake distributes make steps as resources become available, using the qrsh facility with the -inherit option. Since qrsh provides standard output, error output, and standard input handling as well as terminal control connection to the remotely executing make step, only three noticeable differences exist between executing a make procedure locally and using qmake:
The most common use of make is the compilation of complex software packages. Compilation might not be the major application for qmake, however. Program files are often quite small as a matter of good programming practice. Therefore, compilation of a single program file, which is a single make step, often takes only a few seconds. Furthermore, compilation usually implies a lot of file access. Nested include files can cause this problem. File access might not be accelerated if done for multiple make steps in parallel, because the file server can become a bottleneck. Such a bottleneck effectively serializes all the file access. So a satisfactory speed-up of the compilation process sometimes cannot be expected. Other potential applications of qmake are more appropriate. An example is the steering of the interdependencies and the workflow of complex analysis tasks through makefiles. Each make step in such environments is typically a simulation or data analysis operation with nonnegligible resource and computation time requirements. A considerable speed-up can be achieved in such cases. qmake UsageThe command-line syntax of qmake looks similar to the syntax of qrsh:
Note - The -inherit option is also supported by qmake, as described later in this section. Pay special attention to the use of the -pe option and its relation to the gmake -j option. Both options can be used to express the amount of parallelism to be achieved. The difference is that gmake provides no possibility with -j to specify something like a parallel environment to use. Hence qmake makes the assumption that a default environment for parallel makes is configured that is called make. Furthermore, gmake ´s -j allows for no specification of a range, but only for a single number. qmake interprets the number that is given with -j as a range of 1-n. By contrast, -pe permits the detailed specification of all these parameters. Consequently the following command line examples are identical:
The following command lines cannot be expressed using the -j option:
Apart from the syntax, qmake supports two modes of invocation: interactively from the command line, without the -inherit option; or within a batch job, with the -inherit option. These two modes start different sequences of actions:
See the qmake(1) man page for further details. How Jobs Are ScheduledThe grid engine software's policy management automatically controls the use of shared resources in the cluster to best achieve the goals of the administration. High priority jobs are dispatched preferentially. Such jobs receive better access to resources. The administration of a cluster can define high-level usage policies. The following policies are available:
The grid engine software can be set up to routinely use either a share-based policy, a functional policy, or both. These policies can be combined in any proportion, from giving zero weight to one policy and using only the second policy, to giving both policies equal weight. Along with the routine policies, jobs can be submitted with an initiation deadline. See the description of the deadline submission parameter under Submitting Advanced Jobs With QMON. Deadline jobs disturb routine scheduling. Administrators can also temporarily override share-based scheduling and functional scheduling. An override can be applied to an individual job, or to all jobs associated with a user, a department, or a project. | ||||||||
| ||||||||
![]() |