1.4 Distinguishing Features

Checkpoint and Migration.

Users of Condor may be assured that their jobs will eventually complete even in an opportunistic computing environment. If a user submits a job to Condor which runs on somebody else's workstation, but the job is not finished when the workstation owner returns, the job can be checkpointed and restarted as soon as possible on another machine and will keep on executing in this manner until the job is completed. Condor's Periodic Checkpoint feature can periodically checkpoint the job even in lieu of migration in order to safeguard the accumulated computation time on job from being lost in the event of a system failure (such as the machine being shutdown, a crash, etc).

Remote System Calls.

In Condor's Standard Universe execution mode, the local execution environment is preserved for remotely executing processes via Remote System Calls. Users do not have to worry about making data files available to remote workstations or even obtaining a login account on remote workstations before Condor executes their programs there. The program behaves under Condor as if it was running as the user whom submitted the job on the workstation where it was originally submitted, no matter on which machine it really ends up executing on.

No Changes Necessary to User's Source Code.

No special programming is required to use Condor. Condor is able to run normal UNIX programs. The checkpoint and migration of programs by Condor is transparent and automatic, as is the use of Remote System Calls. These facilities are provided by Condor and, if these facilities are desired, only requires the user to re-link their program, not recompile it or change any code.

Sensitive to the desires of workstation owners.

``Owners'' of workstations have by default complete priority over their own machines. Workstation owners are generally happy to let somebody else compute on their machines while they are out, but they want their machines back promptly upon returning, and they don't want to have to take special action to regain control. Condor handles this automatically.

ClassAds.

The ClassAd mechanism in Condor provides an extremely flexible and semantic-free, expressive framework for match-making Resource Requests and Resource Offers. One result is that users can easily request practically any resource, both in terms of what their job requires and/or what they desire for their job if available. For instance, a User can require their job run a machine with 64 megs of RAM, but state a preference for 128 megs if available. Likewise, machines could state for example in a Resource Offer ad that they prefer to run jobs from a certain set of users, and require that there be no interactive user activity detectable between 9 am and 5 pm before starting a job. Job requirements/preferences and resource availability constraints can be described in terms of powerful, arbitrary expressions, resulting in Condor being flexible enough to adapt to nearly any desired policy.