% fortune -ae paul murphy

A sneaky use for the Sun Grid

Sun envisages the Sun Grid as an easy to access, consumer friendly, scientific computing facility. Basically the deal is that you can run standard software, or have them load your own, and pay them $1 per CPU hour to get hundreds, or even thousands, of CPUs focused on your job.

Since there are 8,766 hours to a year and a four core Sun V40 Opteron with 8GB of RAM costs only $6,995 at list price, buying grid hours only makes sense if your volume is too low to justify having your own hardware or the key issue is elapsed time.

Indeed I think Sun is digging itself a hole by using a sound bite in place of a billing metric here: $1 per CPU hour doesn't address the grid's ability to reduce elapsed time on big jobs and raises difficult questions about which CPUs are being deployed - because a CPU hour on a 2.8Ghz Opteron with 8GB of local RAM is more valuable for floating point than a CPU hour on a SPARC IIIi CPU - or a 2.2Ghz Opteron with 2GB of local RAM.

A more sensible metric would change automatically with technology and highlight the most important selling feature. Thus a billing rate based on seven cents per minute in elapsed time reduction relative to running the job on the current high end Sun workstation wouldn't sound as good when quoted in Forbes, but would make more sense from both customer and marketing viewpoints. If a job would take, for example, one minute on the grid, 250 minutes on a V40, and four minutes to transmit in both directions the charge for the 241 minute elapsed time reduction. would come to $16.87.

In general, however, I think the Sun grid is great marketing idea with little future - because interest will last only until IBM's cell developers get their act together and the product in the market. Luckily for Sun, programming and SCO related legal issues are delaying this, but the respite won't last forever - indeed, IBM could easily hang Sun on its own petard if it dropped Linux as the Cell default in favor of OpenSolaris.

On the other hand, I can think of special cases where the grid service, albeit with a slight twist, could make an insanely great amount of sense.

Imagine, for example, that you're the Omaha ground station host and distribution agent for imagery from an earth sensing satelite. You're getting 8GB or larger raw images, and your customers want them spliced, diced, and right now.

Even something as relatively simple as combining perhaps one hundred images taken from a pass over the cornbelt, triming out all but a handful of wavelengths, and then passing them on can use thousands of Opteron CPU hours in an environment where every minute that goes by reduces the value of the end product.

Hand that kind of job over to the Sun grid and you get two benefits: first the processing gets done fast; and equally importantly your customer in Tokyo can get histograms off the data before processing is finished.

In other words, you stick Sun with the data delivery side of the problem as a side effect of hiring them to do processing. And, since image delivery is actually a bigger problem than image processing - this gets you a long term advantage over the guys with the in house Cray, cell, or local grid.

Now, Sun would have to negotiate disk space issues and there are regulatory constraints currently preventing some international operations but, in principle at least, the GRID can be used as a kind of data pipeline in which processing just happens to get done while the data is in transit.

And that's a way cool use for the thing.


Paul Murphy wrote and published The Unix Guide to Defenestration. Murphy is a 25-year veteran of the I.T. consulting industry, specializing in Unix and Unix-related management issues.