What Is Its Application?
The scale-on-demand capability provides a generic mechanism for migrating applications between platforms; the core-count, clock-speed, machine-count, communication protocol, and heterogeneity of target networks are all abstracted from developers. This means that resource calculations are less critical because "getting-it-wrong" doesn't require a re-work; it just means recruiting more or fewer resources.
To illustate, the UK Navy has had so many problems with so-called scalable applications over the years that it typically insists that the CPU load of a delivered system must not exceed 50% (to allow for expansion etc). This doubles hardware costs, heat emissions, footprint, power consumption, weight, single points of failure, spares support, and so on. Even with this precaution in place, a 50% load is just as likely to indicate poor load balance as available capacity, and this may not always be apparent until the contingency is actually required. Because scale-on-demand was demonstrable, this requirement was waived for their Surface Ship Torpedo Defense system (see Case Studies), and as a result, the 50% requirement was replaced by the less onerous requirement that the delivered rack must have the appropriate spare expansion slots (should they be required).
In most cases scale-on-demand technology also means that applications can be developed, debugged, and maintained in a more convenient single-process configuration and then deployed across an appropriate distributed resource. Choice and acquisition of target hardware can also be deferred until a later stage in the project lifecycle.
The technology also has specific application in a number of sectors.
Distributed Real-Time Applications (Military, Oil and Gas, Financial Modeling)
Many of the early adopter projects to date have been distributed real-time applications (see Case Studies). In these cases the translator and runtime settings can be optimized for timeliness. These have included surveillance systems, distributed interactive simulations, and a number of military and commercial sonar with both acoustic and seismic processing capability.
In the real-time case, scale-on-demand capability can be used to optimize for fidelity (simulation and military sonar); adding processing power doesn't necessarily speed-up execution, instead it is utilized to improve the definition of the calculation.
In day-to-day operation, military sonar systems can be required to replay and analyze previously logged data, occasionally run crew training sessions, and at the same time monitor for potential threats. If a threat is detected, processing resources can be automatically withdrawn from the replay and training tasks and then rapidly re-allocated to the more urgent task of tracking and classifying the identified threat(s). This is analogous to the biological response to 'extreme cold' where an individual's resources are necessarily focused on the essential processes that are required for survival, at the expense of protecting an individual's extremities. When a successful Antarctic explorer returns to a sufficiently benign environment, resources are automatically returned to normal without conscious effort.
Distributed Offline Applications (Military, Oil and Gas, Financial, Scientific)
In most cases however, additional CPU is used to reduce task turn around time. This would be the case for some surveillance processing, financial modeling, and post-processing of survey data. Because resources can be dynamically recruited, equipment that is only in use during the day can be pressed into service out of office hours.
Scale-on-demand is also useful for systems that have a periodic (typically 24-hour) demand cycle; the processing that a bank requires, for example. CPU resources can be added, removed, or just re-focused, in response to dynamically changing requirements.
Having implemented, accreted, colonized and built an application; the end result is a set of process executables. The final tool in the Blueprint chain (the Task Manager) provides a convenient means of deploying executables across the available network. Although primarily designed to simplify the management and administration of Blueprint applications, the task manager can be used to configure, deploy and monitor any parallel application.
The tool provides a number of facilities that enable administrators and developers to describe the physical network, create and configure logical networks from the physical hardware, and then deploy application instances across one or more of the identified logical networks.
The Parallel Deployment Language (PDL) allows the task manager to take programmatic control of the application's deployment. As well as making sure that particular processes are "pinned" to particular machines when necessary (usually due to some device or peripheral dependency), PDL will also allocate floating processes to available machines, and do so in a manner that ensures that real-time processes do not come into conflict. PDL can also be used to take appropriate action in the event of unscheduled process exits; typical action would be to kill and redeploy particular associated processes.
The process of taking a set of executable processes and describing how they should execute across a network is referred to as colonization. Colonies consist of master processes and slave processes whereby the master orchestrates the behavior of the colony and the slaves perform the bulk of the processing work.
The runtime scheduler employed by Blueprint makes decisions about the most efficient place to execute given tasks within a colony depending on the distribution of data and whether timeliness is most important (real-time systems) or the highest throughput is desired (off-line systems).
To control the starting and stopping of processes across the network, a task manager application is employed. This provides a means, through the Parallel Deployment Language (PDL) for the network administrator to ensure that appropriate actions are taken to ensure sufficient processing is allocated each application and to generate events in case of under-performance or failure.
For More Information
- Multi-Core OO: Part 1
- Multi-Core OO: Part 2
- Multi-Core OO: Part 3
- Multi-Core OO: Part 4
- Multi-Core OO: Part 5