Sorry, but this is basically grid computing with a slightly different client. As pointed out many times before, most interesting problems right now are IO bound. It turns out that data locality is the most important thing in processing extremely large datasets. That is the key insight in the map-reduce paper and the linchpin to the success or failure of all the distributed map-reduce frameworks that have sprung from it.
Most startups and small scale companies that would see the value in leveraging a system like this simply don't have the right processing profile which would make something like this worth their while. I'm sure if you graphed CPU time per byte of data you'd find a sweet spot where a service like this would speed up jobs rather than slowing them down.
As it happens, most companies that have a high CPU time per byte ratio are either financial firms or pharma. Most of whom not only have their own infrastructure, but would rather close up shop than see their proprietary code out in the wild for competitors to analyze.
And there are already plenty of clients out there for running fourier transforms on possible seti signals.
Most startups and small scale companies that would see the value in leveraging a system like this simply don't have the right processing profile which would make something like this worth their while. I'm sure if you graphed CPU time per byte of data you'd find a sweet spot where a service like this would speed up jobs rather than slowing them down.
As it happens, most companies that have a high CPU time per byte ratio are either financial firms or pharma. Most of whom not only have their own infrastructure, but would rather close up shop than see their proprietary code out in the wild for competitors to analyze.
And there are already plenty of clients out there for running fourier transforms on possible seti signals.