FAQs

A: Entire chapters have be written to answer this question, and in fact, you can read more on the "Why Computation on Demand" section of our web page. But here, in a nutshell, are a number of reasons:

• It's Fast
  Typical HPC applications run on clusters of dozens, maybe hundreds of machines. Computation on Demand can distribute your workload across thousands of systems at a time - that's an order of magnitude greater than multi-million dollar cluster farms. And what's even better, you only pay for what you use - no more, no less.
• It's Inexpensive
  The Frontier Grid Platform harnesses excess computation from existing resources, therefore there is no initial hardware outlay, nor are there costs associated with energy consumption and heat dispensation. In addition, you don't have to hire any additional IT administrators.
• It's Secure
  Parabon has designed the Frontier Grid Platform with security in mind, from the ground up. All communications are encrypted via HTTPS, and untrusted applications are quarantined to run in their own restricted sandbox. As such, providers and developers alike can be confident that their systems won't be harmed by malicious users.
• It's Always Up-To-Date
  Like cars, computers begin to depreciate in value the minute they're sold. What's "cutting edge" today will be obsolete in three years. The Parabon Computation Grid, however, is self-upgrading; as people install the Frontier Compute Engine on newer and faster hardware, the entire grid can take advantage of the current state-of-the-art processors.
• It's Available Today
  Hardware procurement can take weeks, even months to be approved, delivered, tested, and deployed. In today's fast-paced, high-stakes tech industry, you can't afford to let your competitors take advantage of your inability to innovate.

A: No, but...

Java provides a secure sandbox which not only protects the provider's computer from malicious tasks, but also allows the developer to develop her distributed HPC application with confidence, knowing that the results won't be tampered with.

We do, however, allow users to deploy Native Codes (such as C++, Fortran, and Matlab programs) across their own infrastructure, enabling them to build a Virtual Private Grid from their existing desktops, servers, and clusters.

A: Because the Frontier Grid Platform runs across the Internet, there is always a certain amount of latency when transferring data.

Because of this, we encourage developers to consider the Compute-to-Data Ratio of their applications. Ideally, your task will spend most of its time processing a small amount of data, rather than the other way around. (As a counter-example, sending a 50GB database out to a thousand computers would take more time than actually processing the file locally.)

A: Due to the distributed nature of the Frontier Grid Platform (and the security ramifications thereof) tasks run in isolation - meaning computers aren't allowed to talk to each other.

Tasks CAN, however return intermediate results via the central server, which an application may use to launch new tasks. This allows for certain techniques - e.g., evolutionary computation - which take an iterative approach.

A: Developing a rate schedule is non-trivial. There are a number of factors which determine how much WORK a job performs, and the POWER it takes to complete it in a given period of time.

To address these concerns, Parabon has developed a reasonably straightforward approach to measuring the amount of computation a job has used:

• We start by calculating the relative "Capacity" of a given node.
• This is done by running a benchmark (or suite of benchmarks) across the entire grid.
• Faster computers complete the benchmark more quickly than slower ones, so we use the reciprocal of the time to determine the machine's Absolute Capacity.
• We then calculate the average Absolute Capacity of all engines on the grid.
• For each engine, we then compare its Absolute Capacity with the aforementioned average Capacity rating, which gives us that machine's Relative Capacity (or simply "C").
• Therefore, 1C represents the capacity of an "average" node.
• How much you pay is a function of the Capacity of all the nodes working on your job at any one time.
• So if you were running at 1000C, that could mean one thousand "average" computers, five hundred "fast" machines, or two thousand "slow" systems. In any arbitrarily long time period, the amount of WORK performed will be the same.
• The point is, regardless of the ACTUAL speed of the machines, you're charged a NORMALIZED rate, dependent on how much WORK was performed.
• Arbitrary measurements like Gigaflops or Compute-Hours don't take into account real-world factors such as the variance of CPUs, or the patterns of availability resulting from actual people using their desktops.
• Also, it's hard to know when grid users will want to launch jobs, so we have to keep nodes on-hand 24x7 to provide for unpredictable demand. To combat this, we encourage users to "Reserve" time on the grid; that way we can obtain computation during pre-selected time frames.
• Example: A user in New York wants to run a job every night from 02:00-04:00AM EST. We can make a deal with a university in Madrid, Spain to run on their computers from 08:00-10:00AM Central Europe Time.
• Conversely, researchers in California who need access during the day might end up running on a batch of computers in Australia which aren't being used overnight.
• Either way, reserving computation ahead of time allows us to approach sellers in the Computation Market, and secure the necessary resources at the best negotiated price.

A: It's easy... Simply Sign Up For A Free Account, download the Software Developer's Kit (SDK) and follow the Free Tutorials.

A: Absolutely!

One of the major advantages to the Frontier Grid Platform is its ability to provide Software as a Service (SaaS). Third-party developers are encouraged to "sell" their applications in our Application Directory. Many of these applications are applicable across a variety of problem domains - from financial forecasting to chemical modeling and simulation. Chances are, if you have a need, somebody has written (or would be willing to write) software to help you address it.

A: Like any API (Application Programmer's Interface) the Frontier Grid Platform requires learning a new set of conventions - understanding jobs and tasks, and learning the appropriate method calls, etc.

Having said that, however, we've developed the Frontier API to be as straightforward as possible. We provide ample documentation and example code, so getting up and running should be a snap. If you've ever struggled with deploying HPC applications across a cluster using other technologies, such as Condor or PVM, you should find our API very clean and concise.

A: Yes, but...

In order to protect providers from malicious users, as well as ensure reliable operation on untrusted resources, we make extensive use of the protections offered by the Java sandbox.

Having said that, however, we do offer users with existing Native Codes (C++, Fortran, Matlab, etc.) the ability to run on their OWN resources - trusted desktops, servers, and clusters, for example - while still enjoying the same reliability and ease-of-use as those applications running "in the wild."

Our Frontier Rapids^™ development kit makes it easy to adapt your existing application to run on the Frontier Grid Platform.

A: Third-party developers can submit their applications for inclusion in our Application Directory. As users pay to use your software, we'll share those proceeds with you. It's our way of saying, "Thanks!" for helping us make Frontier the premier distributed computing platform, and encouraging the use of Computation on Demand.

A: The Parabon Computation Grid depends on people like yourself running the Frontier Compute Engine to power the Frontier Grid Platform.

Much of our work directly benefits the Compute Against Cancer project, which provides resources for Cancer researchers - from researchers studying risk factors, to pharmaceutical companies developing a cure, there are numerous ways in which your computer can help fight Cancer and other illnesses.

In addition, institutional providers - universities and businesses who can offer 25C or more - are eligible for financial compensation, meaning we'll BUY your excess computation. Just as mutual fund managers package up individual stocks, we can bundle together pockets of computational capacity and sell it en masse to power-hungry users around the world. In return, you can maximize your Return on Inves™ent (ROI) AND put your existing resources to good use.

A: Recall the quote, "Everything should be made as simple as possible, but not simpler" by Albert Einstein. Metrics like CPU-hours and VM instances are meaningful only when applied to the simple case of completely homogenous resources. Because we aggregate capacity across a vast array of different computers and operating systems, we had to invent a means measuring and normalizing it across heterogeneous resources.

A: The PCI serves different audiences:

The economics of computation is different from that of all other commodities in one important way: The quantity supplied and the quantity demanded are both increasing dramatically over time - to the tune of ~50% per year! We could have defined and permanently fixed some unit of computational power, akin to the definition of a watt of electric power, however, practical use of such would quickly become unwieldy and decreasingly useful for valuation purposes. For computation to be treated as a commodity, suppliers and providers need a practical means of quantifying and valuing it. Fundamentally, the price of computation is based on, among other things, the total cost of ownership of the computational resources that provide it. A computer "of the capacity you might buy today," is something to which we can all relate; by contrast, the computational capacity and inflation-adjusted price of a computer that is, say, five years old is hard to compare to contemporary computers. Thus, if the unit measure of computational capacity (and power) was permanently fixed to the capacity of some designated "standard," (i.e., the capacity of a specifically designated computer with designated bandwidth), the measure would quickly become unwieldy (thanks to the Laws of Moore and Gilder); more significantly, it would grow ever less useful for the purpose of comparison and valuation in the marketplace.

A: Unlike other benchmarks, the PCB assigns a capacity rating based on factors, besides raw computational performance, that affect an engine's potential contribution to a computational grid, e.g., availability, reliability, bandwidth and the memory allocated to its compute engine.

A: No. First, the Basic Capability Index (BCI) of an individual engine is periodically recalibrated to account for its performance history, although over time the BCI for an engine does tend to equilibrate to a fixed value provided the influencing factors do not change dramatically. The Parabon Capacity Index of an engine, however, will decline over time. As ever-faster computers are added to the pool of available resources, the relative capacity of an engine naturally declines. As a corollary to Moore's Law, an engine with a PCI of 1.0 today is expected to have a PCI of 0.5 within 18-24 months.

A: In time, we will. For now, it is only cost effective for us to purchase from large institutional providers (e.g., universities, businesses and municipalities) that can provide large blocks of capacity.