The Scientific Cloud

The following represents data and results gathered from the second research institution connection cloud transfer test and compares results from Azure’s US North Central data center and Azure’s US South Central data center. The methodology applied during this test is detailed here and should be reviewed prior to considering the results or commentary below.

Test Overview:

• 05561 Cloud Transfer Tests: Research Institution Test 02
• Local Connection: Research Networks
• Started: February 9, 2010
• Finished: February 16, 2010
• Origination Point: Oak Ridge, TN

Disclaimer:

• Standard Disclaimer Applies

Test Objectives:

• Standard objectives apply
• Specific to this test: Test a research institution connection as the researcher’s “workstation” and gather data aimed at building a realistic expectation of performance

Test Setup

• Included File Sizes:
  • 2KB, 32KB, 64KB, 128KB, 256KB, 512KB, 1MB, 5MB, 10MB, 25MB, 50MB, 100MB, 250MB, 500MB, 750MB, 1GB
• Network Connectivity - “research institution”
  • Consists of a computer connected to a local network router via 100Mbps hard-wire.
  • Multiple switches/routers/firewalls may exist between workstation and the public internet
  • There may exist multiple high-speed networks that may be leveraged for connectivity to remote datacenters (ESNet, I2, NLR
  • Reasonable effort has been made to ensure that no other applications or TSRs are running on the source computer for the duration of the test.
  • For this test, a newly-installed Windows 7 Professional installation was used, fully patched, with no other applications (beyond the test harness) installed.

Test Execution:

• Standard execution approach applied with the exception of the fact that Azure was tested for both cases – simply different datacenters (see slides for details)

Report Generation

• Standard report generation approach applied

Conventions:

• Standard conventions apply

Resources:

• Standard resources apply - no test-specific customizations beyond adaptations for the specific file sizes included in the test

Results:

Similar to other tests, there is some variability displayed that is obviously a result of traffic issues. We are continuing to look into this.

In general, the data from the Azure US North Central data center proved better than that of US South Central which is not altogether surprising as we are physically closer to the USNC location.

Slides 171 and 172 remain disturbing as the download values for the 750MB file size continue to be outside of what would be expected.

Slide 172 in particular is of interest as it draws attention to some wide variability across file sizes for the USSC datacenter (not just the 750MB size).

Full results are available in slide form here:

PDF of results are available here: http://sciencecloud.us/media/05561_Xfer-Research_02.pdf

The following represents data and results gathered from the first research institution connection cloud transfer test. The methodology applied during this test is detailed here and should be reviewed prior to considering the results or commentary below.

Test Overview:

• 05561 Cloud Transfer Tests: Research Institution Test 01
• Local Connection: Research Networks
• Started: February 8, 2010
• Finished: February 16, 2010
• Origination Point: Oak Ridge, TN

Disclaimer:

• Standard Disclaimer Applies

Test Objectives:

• Standard objectives apply
• Specific to this test: Test a research institution connection as the researcher’s “workstation” and gather data aimed at building a realistic expectation of performance

Test Setup

• Included File Sizes:
  • 2KB, 32KB, 64KB, 128KB, 256KB, 512KB, 1MB, 5MB, 10MB, 25MB, 50MB, 100MB, 250MB, 500MB, 750MB, 1GB
• Network Connectivity - “research institution”
  • Consists of a computer connected to a local network router via 100Mbps hard-wire.
  • Multiple switches/routers/firewalls may exist between workstation and the public internet
  • There may exist multiple high-speed networks that may be leveraged for connectivity to remote datacenters (ESNet, I2, NLR
  • Reasonable effort has been made to ensure that no other applications or TSRs are running on the source computer for the duration of the test.
  • For this test, a newly-installed Windows 7 Professional installation was used, fully patched, with no other applications (beyond the test harness) installed.

Test Execution:

• Standard execution approach applied

Report Generation

• Standard report generation approach applied

Conventions:

• Standard conventions apply

Resources:

• Standard resources apply - no test-specific customizations beyond adaptations for the specific file sizes included in the test

Results:

Across both services there exists an interesting amount of variability that is likely due to intermediate traffic or traffic management issues. Even within the same test run (see various scatter plots) you can detect “walls” of change wherein a the values will be hovering around a certain value and subsequently they hover around a much higher/lower value (ex. slide 133, 134).

There is not a consistent “winner” in this report. for various file sizes one platform would clearly outperform the other only to have the tables completely reversed for the next file size. This hints at network routing issues. A brief conversation with some of our local networking team indicates that some traffic (in particular Amazon’s) appeared to generally leave via the router connected to ESNet whereas most of the Microsoft traffic would leave via the router connected to Southern Crossing with subsequent connections to I2 and NLR. It may well be that the insertion of some static routs may help address some of the stability issues here.

Of particular interest is the “hump” seen by both services in slide 170. This has been seen in a similar location on the chart in other runs (see slide #82 here: http://www.slideshare.net/rgillen/cloud-storage-upload-tests-02). We don’t yet have a good explanation for this shape in the curve and are hoping to track that down soon.

Further, the shape of the Azure curve in slide 171 is inconsistent with other tests – specifically the data points for the 750MB size. We will continue to compare with other sets/runs to see if this continues or was simply transient.

What remains consistent across all tests so far is that the level of variability tends to be greater with the S3 platform as compared to the Azure Blob storage.

Full results are available in slide form here:

PDF of results are available here: http://sciencecloud.us/media/05561_Xfer-Research_01.pdf

The following represents data and results gathered from the first consumer connection cloud transfer test. The methodology applied during this test is detailed here and should be reviewed prior to considering the results or commentary below.

Test Overview:

• 05561 Cloud Transfer Tests: Consumer Connection Test 01
• Local Connection: Comcast Residential
• Started: February 9, 2010
• Finished: February 14, 2010
• Origination Point: Knoxville, TN

Disclaimer:

• Standard Disclaimer Applies

Test Objectives:

• Standard objectives apply
• Specific to this test: Test a consumer/commodity connection as the researcher’s “workstation” and gather data aimed at building a realistic expectation of performance

Test Setup

• Included File Sizes:
  • 2KB, 32KB, 64KB, 128KB, 256KB, 512KB, 1MB, 5MB, 10MB, 25MB, 50MB, 100MB
• Network Connectivity - “typical home network”
  • Consists of a computer connected to a local router via 1GE hard-wire.
  • Router is then directly connected to service provider’s modem
  • Consumer has a “general” plan for internet connectivity
  • Reasonable effort has been made to ensure that no other applications or TSRs are running on the source computer for the duration of the test.
  • For this test, a newly-installed Windows 7 Professional installation was used, fully patched, with no other applications (beyond the test harness) installed.

Test Execution:

• Standard execution approach applied

Report Generation

• Standard report generation approach applied

Conventions:

• Standard conventions apply

Resources:

• Standard resources apply - no test-specific customizations beyond adaptations for the specific file sizes included in the test

Results:

In contrast to some other test runs on other networks, in this test Azure seemed to generally (if barely) out-perform the Amazon platform and, consistent with other tests, Amazon’s interaction with Amazon’s platform shows greater variability across a given file size.

The test was limited to file sizes up to and including 100MB so as to avoid being flagged by the residential ISP for poor traffic habits (an issue to be addressed for large-bandwidth users on consumer connections).

Full results are available in slide form here:

PDF of results are available here: http://sciencecloud.us/media/05561_Xfer-Consumer_01.pdf

[NOTE: these are simply introductory tests and should not be considered scientifically accurate comparisons of the various platforms]

The second run of the tests used the defaults for the parameters as provided in the original sample with the exception of the “runs” parameter which was increased from 1,000,000 to 10,000,000. The test bed used is detailed here and the results of the first run are here. The net-net is that the calculation is run 100 times and each time contains a loop that runs 10,000,000 times. Each run of the calculation can be run independently of the others as the aggregation/summation is handled in the spreadsheet once the calculations have finished. To provide some protection from anomalies, I ran each test against each platform 10 times with the first run being “cold”.

Results:

The time values on the Y axis are seconds to complete the execution. In this run, a few things jump out:

• As in the first test, the 2-node HPC cluster killed the other two. Again this isn’t surprising, although I’d like to think that as the compute to communication ratio grows, the delta b/t the HPC cluster and Azure will shrink.
• In contrast to the first run, in this run Azure beat the local run by an average of nearly 200 seconds/run. This is consistent with the theory that the communication overhead in the Azure solution is constant per request regardless of the complexity of compute resulting with the communication overhead becoming marginalized as the compute to communicate ratio increases.

I’m currently performing tests that take the runs parameter to 100,000,000 which should separate the three platforms further and it is expected that unlike the first two runs, Azure will be closer to the HPC results than to the local compute results (although the HPC cluster is still expected to outperform Azure).

[NOTE: these are simply introductory tests and should not be considered scientifically accurate comparisons of the various platforms]

The first run of the tests used the defaults for the parameters as provided in the original sample. The test bed used is detailed here. The net-net is that the calculation is run 100 times and each time contains a loop that runs 1,000,000 times. Each run of the calculation can be run independently of the others as the aggregation/summation is handled in the spreadsheet once the calculations have finished. To provide some protection from anomalies, I ran each test against each platform 10 times with the first run being “cold”.

Results:

The time values on the Y axis are seconds to complete the execution. In this run, a few things jump out:

• The 2-node HPC cluster killed the other two. This is not altogether surprising, especially considering the processor power is significantly better than the other two scenarios and this is the only scenario where the compute is happening on raw hardware (the “local” development machine is virtualized and I believe that the node instances hosted in Azure are also virtualized.
• The HPC cluster took one run to “warm up” after which the performance was remarkably solid.
• The “Local” (sequential) run beat the Azure (parallel) run. At first this might be surprising, but it really isn’t when you think about it. The Azure model has a certain communication overhead for each request (HTTP sending of each request to azure, communication b/t the web and worker roles via the queue, storage of results in the Azure tables, and the retrieval of the results). In this test run, the compute per run is not significant (averaging just over 0.5 seconds on the local box per calculation) and the communication overhead stands out more. It is supposed that in subsequent runs where the compute is heavier, the two will trade places.

I’m working through some basic performance testing and comparisons for cloud compute and this post is intended to provide a bit of detail regarding the test platform I’m using for conducting these tests. I should also be clear that the test platforms below are not designed to be perfect-world hardware platforms, but rather proof-of-concept and suitable for order-of-magnitude testing.

General Code Base

For this aspect of testing I have been working with the Asian Options Pricing WCF sample provided by Microsoft on the HPC resource kit site (http://resourcekit.windowshpc.net/). This is a simple VSTO-enabled worksheet that calculates the price of an option on the Asian market. I’m by no means a market analyst nor can a vouch for the accuracy of the calculation, but it does provide a CPU-intensive operation that can be parallelized easily making it a good candidate for scale-out compute. The sample is designed to be illustrative of submitting WCF jobs (‘micro jobs’) to a Windows HPC cluster and comes with source and instructions for getting it setup and running.

In the default configuration, the worksheet performs 100 iterations of Monte Carlo pricing runs using a function called PriceAsianOptions (code listed at the bottom of this post). The basic theory may be understood better by reading this article. The function takes the following input parameters:

• Up – the specific factor by which the underlying instrument may move up per step of the binomial price tree
• Down – the specific factor by which the underlying instrument may move down per step of the binomial price tree.
• Interest – the continuously compounded, risk-free interest rate. This number doesn’t affect the complexity of the calculation so I left it constant.
• Initial Price – the starting or current price of the stock. I left this constant as it doesn’t affect the complexity of the calculation
• Periods – the number of periods (trading days) before the option expires. The default was 20 and I left this constant. Technically it could increase the complexity of the calculation but changing the value of the Runs parameter does a suitable job of this.
• Exercise – the price at which the call should be exercised
• Runs – within a given calculation, how many times should the calculation be done prior to averaging and returning the results. This defaulted to 1,000,000 and is the prime value that I altered during the runs to increase the duration of the calculation.

Once the worksheet has finished calculating, a batch (by default 100 such calls to PriceAsianOptions) it calculates and displays the Average of the Monte Carlo runs, the Min, Max, Standard Deviation, Standard Error, and Execution Time in seconds.

NOTE: this test platform is much less about the specific problem being solved and more about taking a CPU/Compute intensive problem and expressing it on different platforms.

Windows HPC Server Environment

Hardware: My test environment consists of a small cluster with one head node and two compute nodes. The head node is a single-proc box running with 2 GB of RAM and 2 NICs. Besides the cluster Head Node role, it is also running DNS, DHCP, AD, SQL and has the WCF broker role (it does *not* have the compute role). Each compute node is a dual core Intel box with 4 GB RAM running Windows 2008 HPC Server. The cluster is configured such that the head node has one leg on the “enterprise network” (in my corner of the universe this is simply my lab network) and another leg on the private network shared with the compute nodes. The individual compute nodes are not accessible from outside this private network.

Software: While the instructions and download would lead you to believe that the code is ready to run out-of-the-box (OOTB) that is not quite true. Beyond the changes detailed in the instructions, I had to make some changes in additional locations for the name of the cluster’s head node as well as that to the dll as seen from the compute nodes. Beyond those changes however, the code used in the tests is identical to what is available on the resource kit site. The main logic is a loop to submit n jobs, with each request having an asynchronous event to process the results.

Local Compute Environment

Hardware: The platform I’m using for the “local machine” compute tests is a Windows Server 2008 Standard box (64 bit) with 4 GB of RAM and a single 2.4 Ghz processor. This certainly isn’t anything fancy but should provide a middle-of-the-road hardware spec for comparison to the other platforms.

Software: I started by taking the worksheet used for the HPC environment and added another button for the “local” runs. Since the hardware I’m running on only has a single processor, I adjusted the logic loop to not be parallelized (additional threads would simply harm performance) but rather sequential. The work is performed on a background thread and as soon as an individual computation is completed the UI is notified/updated.

Azure Environment

Hardware: The configuration for the test bed as hosted in Azure is split over two projects. The first project is the data project (used for queues and tables) and is not part of any affinity group and is configured for a geographic location of USA-Anywhere.  The second project is the compute project and is configured with one web role and two worker roles. It is also not part of an affinity group and is configured with a geographic location of USA-Anywhere. NOTE: the lack of specifically selecting an affinity group or geographic location is to provide a sort of worst-case scenario assuming that selecting either of those would, if anything, only improve the performance.

Software: There was a good bit more coding to do here as I attempted to mimic (in theoretical approach at least) the general implementation of WCF services on Windows HPC. The web role is host to a WCF service that allows a client (in this case the Excel worksheet) to submit a single pricing request (providing the parameters explained above). This pricing request and parameters is serialized and placed on the Azure queue to be picked up by one of the running worker roles (incidentally, one nice side affect of this approach is that from a coding standpoint it makes no difference how many worker roles exist – if more are needed they can simply be configured and items will be processed off the queue in a quicker fashion). Once the worker role picks up the pricing request/data, it processes the request and places the resulting price (and a the request identifier) into a row in an Azure table. At this point it checks the queue again for the next pricing request. An additional method exists in the WCF service that accepts a request ID and then looks at the azure table for a result matching that request ID. If one is found, the result is returned and the data removed from the azure table.

On the Excel worksheet side, I modified the same worksheet as before with yet another button for submitting the work to the Azure-hosted WCF service. I took a similar loop to the other two scenarios but made the adjustment that it will first submit all of the requests and only then will it begin asking for the results. The idea is to avoid having the requests for results clogging the network and slowing down the submission of jobs – I wanted to keep the worker roles as busy as possible until the work was done. I initially implemented this using a similar approach to the HPC code (async anonymous methods handling the results) but this failed as the tests grew bigger because of the default web server timeouts (i.e. I’d have 100 requests queued and it was likely that more than 90 seconds would pass before the results were finished).

Sample Code

private double PriceAsianOptions(double initial, 
    double exercise, double up, double down, double interest, 
    int periods, int runs)
{
    double[] pricePath = new double[periods + 1];

    // Risk-neutral probabilities
    double piup = (interest - down) / (up - down);
    double pidown = 1 - piup;

    double temp = 0.0;

    Random rand = new Random();
    double priceAverage = 0.0;
    double callPayOff = 0.0;

    for (int index = 0; index < runs; index++)
    {
        // Generate Path
        double sumPricePath = initial;

        for (int i = 1; i <= periods; i++)
        {
            pricePath[0] = initial;
            double rn = rand.NextDouble();

            if (rn > pidown)
            {
                pricePath[i] = pricePath[i - 1] * up;
            }
            else
            {
                pricePath[i] = pricePath[i - 1] * down;
            }
            sumPricePath += pricePath[i];
        }

        priceAverage = sumPricePath / (periods + 1);
        callPayOff = Math.Max(priceAverage - exercise, 0);

        temp += callPayOff;
    }
    return (temp / Math.Pow(interest, periods)) / runs;
}