[Swift-commit] r6231 - trunk/docs/userguide

[ketan at ci.uchicago.edu]

Author: ketan
Date: 2013-02-04 08:27:24 -0600 (Mon, 04 Feb 2013)
New Revision: 6231

Modified:
   trunk/docs/userguide/coasters
Log:
polishing coaster desc

Modified: trunk/docs/userguide/coasters
===================================================================
--- trunk/docs/userguide/coasters	2013-02-04 05:32:22 UTC (rev 6230)
+++ trunk/docs/userguide/coasters	2013-02-04 14:27:24 UTC (rev 6231)
@@ -3,40 +3,39 @@
 
 Introduction
 ~~~~~~~~~~~~
-In many applications, Swift performance can be greatly enhanced by the
-use of coasters. Coasters provide a low-overhead job submission
-and file transfer mechanism suited for the execution of short jobs (on
-the order of a few seconds) and the transfer of small files (on the
-order of a few kilobytes) for which other grid protocols such as GRAM
-and GridFTP are poorly suited.
+Coasters are the Swift's implementation of _pilot job abstraction_.
 
+In many applications, Swift performance can be greatly enhanced by the use of
+coasters. Coasters provide a low-overhead job submission and file transfer
+mechanism suited for the execution of jobs and the transfer of files for which
+other grid protocols such as GRAM and GridFTP are poorly suited.
+
 Benefits
 ~~~~~~~~
+Much of the overhead associated with other grid protocols (such as
+authentication and authorization, and allocation of worker nodes by the site's
+local resource manager) is reduced, because that overhead is associated with
+the allocation of a coaster pilot or coaster worker, rather than with every
+Swift-level procedure invocation; potentially hundreds or thousands of
+Swift-level procedure invocations can be run through a single worker. Coasters
+can be configured for two purposes: job execution and file staging. In
+practice, the Swift script remains the same while working with coasters. A
+detailed description of coaster mechanism is explained in the next section.
 
-The coaster mechanism submits a pilot job using some other execution
-mechanism such as GRAM, and for each worker node that will be used in a
-remote cluster, it submits a worker job, again using some other
-execution mechanism such as GRAM. Details on the design of the coaster
-mechanism can be found here. <http://wiki.cogkit.org/wiki/Coasters>
-
 Mechanism
 ~~~~~~~~~
+Coasters run at the task management layer logically under the Swift script. The
+jobs and data movement requirements resulting after the interpretation of a
+Swift script are handled by the coasters. The coaster mechanism submits a pilot
+job using some other execution mechanism such as GRAM, SGE or PBS scheduler,
+and for each worker node that will be used in a remote cluster, it submits a
+worker job, again using some other execution mechanism such as GRAM. Details on
+the design of the coaster mechanism can be found here:
+<http://wiki.cogkit.org/wiki/Coasters>. The pilot job manages file transfers
+and the dispatch of execution jobs to workers. 
 
-The pilot job manages file transfers and the dispatch of execution jobs
-to workers. Much of the overhead associated with other grid protocols
-(such as authentication and authorization, and allocation of worker
-nodes by the site's local resource manager) is reduced, because that
-overhead is associated with the allocation of a coaster pilot or coaster
-worker, rather than with every Swift-level procedure invocation;
-potentially hundreds or thousands of Swift-level procedure invocations
-can be run through a single worker.
-
-Coasters can be configured for two purposes: job execution and
-file staging.
-
 Coasters How-to
 ~~~~~~~~~~~~~~~
-
 To use for job execution, specify a sites.xml execution element like this:
 
 ----
@@ -45,10 +44,10 @@
 
 The jobmanager string contains more detail than with other providers. It
 contains either two or three colon separated fields: 1:the provider to
-be use to execute the coaster head job - this provider will submit from
+be use to execute the coaster pilot job - this provider will submit from
 the Swift client side environment. Commonly this will be one of the GRAM
 providers; 2: the provider to be used to execute coaster worker jobs.
-This provider will be used to submit from the coaster head job
+This provider will be used to submit from the coaster pilot job
 environment, so a local scheduler provider can sometimes be used instead
 of GRAM. 3: optionally, the jobmanager to be used when submitting worker
 job using the provider specified in field 2.
@@ -60,10 +59,10 @@
 ----
 
 The url parameter should be a pseudo-URI formed with the URI scheme
-being the name of the provider to use to submit the coaster head job,
+being the name of the provider to use to submit the coaster pilot job,
 and the hostname portion being the hostname to be used to execute the
-coaster head job. Note that this provider and hostname will be used for
-execution of a coaster head job, not for file transfer; so for example,
+coaster pilot job. Note that this provider and hostname will be used for
+execution of a coaster pilot job, not for file transfer; so for example,
 a GRAM endpoint should be specified here rather than a GridFTP endpoint.
 
 Coasters are affected by the following profile settings, which are