Thursday, February 17, 2005
Grid computing
IIT-Kanpur will soon deploy Sun's grid computing solution.
Sun's Compute grid rack system is an ideal solution for compute-intensive applications. It is an integrated solution that delivers high compute performance, excellent price/performance, and high density.
Sun's President and Chief Software Blogger Jonathan Schwartz had blogged on Sun's move into grid computing, and offered IBM a challenge.
We're well aware that grids are inappropriate for many of today's applications or customer environments. But there's a broad market of workloads that are right in our crosshairs, from risk analysis to movie rendering, data warehousing to reservoir simulation. We understand full well that this represents a very small portion of today's computing needs. But we also know that's where the network's headed - that more traditional apps are spilling into the grid, and the market's growing.
So in the spirit of giving IBM an opportunity to respond with greater clarity, here's a table presenting what $1/cpu-hr buys you from Sun.
Sam, we hereby invite you to fill in the blanks
At $1 per CPU-hour and $1 per GB-month, Sun is confident that it has a great price point, but the question is also one of quality - will the Sun grid deliver the same level of performance, scalability, reliability and fault-tolerance as IBM's computing solution?
UPDATE :
[From Sadagopan's blog] David Berlind talks about grid computing on ZDNet, and the different types of applications possible.
The first and perhaps simplest type of grid application is the one that most closely resembles dynamic provisioning, where you dynamically realign system configurations based on the priorities of certain business objectives.
The second type of application concerns array jobs. This is the one that most closely resembles the SETI@home project because of the way multiple machines are working on the same problem, but with independently processable chunks of data.
Since there are different types of grid applications envisioned, what constitutes an appropriate benchmark workload for the grid will depend on what the grid ends up being primarily used for - for array computing, for Condor ClassAd-style load balancing, or for applications requiring tighly coupled systems. I suspect that like the differentiation of the TPC benchmarks into TPC-C and TPC-H, grid benchmarks might also get differentiated, and that it might be nescessary to look at multiple benchmark numbers to evaluate a particular grid.
Sun's Compute grid rack system is an ideal solution for compute-intensive applications. It is an integrated solution that delivers high compute performance, excellent price/performance, and high density.
Sun's President and Chief Software Blogger Jonathan Schwartz had blogged on Sun's move into grid computing, and offered IBM a challenge.
We're well aware that grids are inappropriate for many of today's applications or customer environments. But there's a broad market of workloads that are right in our crosshairs, from risk analysis to movie rendering, data warehousing to reservoir simulation. We understand full well that this represents a very small portion of today's computing needs. But we also know that's where the network's headed - that more traditional apps are spilling into the grid, and the market's growing.
So in the spirit of giving IBM an opportunity to respond with greater clarity, here's a table presenting what $1/cpu-hr buys you from Sun.
Sam, we hereby invite you to fill in the blanks
At $1 per CPU-hour and $1 per GB-month, Sun is confident that it has a great price point, but the question is also one of quality - will the Sun grid deliver the same level of performance, scalability, reliability and fault-tolerance as IBM's computing solution?
UPDATE :
[From Sadagopan's blog] David Berlind talks about grid computing on ZDNet, and the different types of applications possible.
The first and perhaps simplest type of grid application is the one that most closely resembles dynamic provisioning, where you dynamically realign system configurations based on the priorities of certain business objectives.
The second type of application concerns array jobs. This is the one that most closely resembles the SETI@home project because of the way multiple machines are working on the same problem, but with independently processable chunks of data.
Since there are different types of grid applications envisioned, what constitutes an appropriate benchmark workload for the grid will depend on what the grid ends up being primarily used for - for array computing, for Condor ClassAd-style load balancing, or for applications requiring tighly coupled systems. I suspect that like the differentiation of the TPC benchmarks into TPC-C and TPC-H, grid benchmarks might also get differentiated, and that it might be nescessary to look at multiple benchmark numbers to evaluate a particular grid.
