How do your paying customers feel about their data being strewn about the Internet? How does your processing interfere with the game that the user is playing? What kind of problems have you earmarked as being particularly parallelizable like this (ie what is your marketing plan?), and how usable is your API?
At the end of the day, is going through the effort to rewrite a program to work on distributed Java applets going to produce substantially more processing for the customer dollar than a $150 headless dual-core 1gz board with a gig of RAM running C++? You say that you can provide a $1500/yr savings over EC2, but this is only for applications that are "embarrassingly parallel", and will certainly require hiring a programmer to write code to run in tiny chunks on lots of clients. Will this cost less than $1,500? Worse, it will be money up front instead of spread out over a year.
You could say that the system is best leveraged by clients looking for a lot of compute power on a budget, but those are the people most likely to build their own grid. When you can get linux running on a dual-core 2.0gz for $200 / node, spending that money every year on an untested platform that will require substantial development work and vendor tie in, your service is going to be a tough sell.
You will be the only people interested in writing code for this platform, so please repost when you know which algorithm you can run to gross $10 million a year.
First, $1500/node-year (or even $200/node-year) comes to a very substantial amount of money for our target customers. These customers use 10000s of nodes and buy high-end computers and pay a ton for network, power, cooling, and support personnel.
My background is in HPC and I've faced and solved these issues many times. We have a multi-pronged approach to using the compute power:
1) We are definitely writing our own apps on top of Plura. It's a great source of compute power and we have lots of ways we want to use it ourselves.
2) We have a short list of very high impact embarrassingly parallel customers that are evaluating Plura. We intend to help our customers absorb the porting cost associated with Plura.
3) We are open to letting students and universities use Plura's excess capacity for free. We've had several nibbles at this already.
That being said, we realize Plura is not for everyone. It is for a subset of the class of embarrassingly parallel applications out there.
When I run any process I expect it to restrict all its actions to servicing direct functions related to that process. Plura is expressly unrelated to ANY process/game it is bundled with.
I would personally be annoyed/angry that a program I was using, web-based or not, was using my computer's resources to make money without my knowledge. In fact, you're not just using my computer's resources, you're also drawing more power from my electrical grid, because a processor doing more work consumes more electricity. That's something that directly costs me, the end user, more money. So I would absolutely classify this as theft of service unless the user explicitly agrees to have Plura running in the background.
If there is ample warning to the user, I am fine with this, and would consider it a good idea. Otherwise, it feels really sleazy and wrong.
A ton of flash ads might have a bigger impact on your system performance (and on your wallet, if your ISP charges by traffic)
Our hope is that the users end up reaping the benefits from this via increased development dollars or reduced ads. We have some affiliates that are exploring ways of giving some form of in-game currency in exchange for Plura time. For example, you might earn more gold, a better performing sword, higher production, or something like that.
Legally speaking if the game (or whatever) doesnlt make 100% clear what is going on ("we are going to be using your CPU") then I'd say it's very shaky territory.
Also I am pretty sure that in a lot of countries you would be pretty much required to either have a splash saying "click yes to play this game and work some units" or have a workable opt out (I dont know if that exists??)
I submitted our game page as the HN link, but www.pluraprocessing.com has more general information.
Take a look and tell me what you think. We've been paying our alpha affiliates for months now and are ready to take on a much larger pool of affiliates in our beta. "Affiliates" are the people that put Plura on their site, browser game, or other content (even download apps) and get paid for their user time.
And, yes I totally agree.
Also privacy issues in the entire concept. I didn't notice any (note: I didn't go out of my way to find one either) way for the end users to directly go and see exactly what kind of materials were being processed and what data, if any, was being collected from the user's machine. That might also be a source of trouble in the long run.
Second, although we encourage disclosure, we leave the disclosure up to the individual sites and some have chosen to use some form of opt-out or opt-in. That being said, we also provide a TOS that they can use for disclosure if they choose. If the disclosure is done in a positive way, the users should see the benefits of getting more game features for free.
"After receiving the WU, the user's computer will perform the computation. The game developer can control how much of the user's CPU is devoted to computation by setting the % usage (either statically or dynamically)."
How do you accurately control the amount of CPU a program takes in user-space? Can you really have a process that will restrict itself to using no more than 25% CPU? (Also, 25% of a fast CPU is more than 25% of a slow one)
As far as the fast versus slow nodes, we normalize everything based on the average computer that completes work each day. So a fast computer may earn 2X or more what a slow computer earns.
It sounds dishonest to summarize this as 2.60$ per user per month. It is 2.60$ per user, if that particurlar user plays non-stop for 30 days straight, assuming 100% CPU
In other words, you get 1 cent per 3 hours of play time. To get 100$ per month, you need 10000 users, playing one hour every week or so. (hopefully, my math and interpretation is correct)
For websites and other affiliate types, we say we pay $15/MWU (million work units) where a work unit is 15 seconds on an average node (the system-wide Plura average node performance).
That said this is a pretty cool model, and I'm sure that most people would be happy to let a few of their CPU cycles pay for the game they are playing.
In other words I really really really don't like hidden or undisclosed functionality in whatever the software I am running. Especially if it is explicitly designed to utilize my otherwise idle resources.
Few years back my friends and I were talking about putting a DES brute-forcing client into a flash applet and then sticking it on a high-traffic site. It never went anywhere beyond a discussion though exactly because of the ethical issues involved.
There is no question there will be plenty of affiliates/CPU time (re)sellers.
The real question is whether there is big enough demand from those who need grid computing.
Here's a blog post we wrote comparing us to Amazon's EC2 for HPC apps: http://pluraprocessing.wordpress.com/2008/10/23/comparing-pl.... Our numbers should be very compelling for certain types of applications compared to the cost of building your own clusters or using an EC2-type service.
There are definitely certain applications where this form of grid or cloud computing (I hate to use such a popular buzzword) will enable apps that weren't possible before. Previous attempts at grid computing for HPC depended more on philanthropy instead of having a scalable business model that allowed the addition of 100s and 1000s of nodes at a time.
2) You maybe should look at the phrase on savings in your paper:
"if your application is suitable for Plura, you can save 7X on your compute costs".
I take this to mean you save 7 times your compute costs, where it should be six sevenths of the cost. There's a difference, and your customers will understand it. Sorry if I've just misunderstood.
We have one company (80legs.com) that is developing a web crawling solution using Plura. We are using a different model to acquire the nodes for this.
nice indeed ;P
Also, what is the average CPU percentage your developers run on their clients systems?
The type of sites you mention will work well too. Send us a note through the Contact Us page on the website and we can help you figure out how much you could earn.
Lets assume you have a gigabit line out of your colo. Lets also assume that your average game client is on a cable modem with a 1megabit connection. That gives you capabilities to stream work units to 1024 clients simultaneously as an upper limit. In keeping with an average 1 megabit client, it will take 3 minutes to stream down a 20 megabyte work unit, maxing their connection. 1024 concurrent clients * 20 megabytes = 20 gigabytes. So you're looking at 3 minutes of overhead transfer out, and likely another 3 minutes or so of overhead transfer of results back from the client. So that's approximately 6 minutes per gigabyte just in transmission overhead. And it gets worse as clients are added to the system, since you would need scale out your datacenter just to handle coordinating all of the clients. Which begs the question: why aren't all those servers just doing the dang work already?
That kind of overhead limits this technique's usefulness only to applications which have relatively high computational complexity and relatively small amounts of data. And those applications do exist, however they're pretty far from the day to day needs of most companies. Sun found this out the hard way with their Sun Grid project, which last time I checked was a failure. Sorry, I really wish you the best of luck.
We are definitely focused on the applications that have extremely high compute/io ratios. In general, these boil down to either high compute problems with no real data or problems where the data can be shared between multiple work units. An example of the latter is stock market analysis - the nodes download stock data for a few stocks and stay busy running different combinations for a very long time.
There is some protection in the fact that you never know what type of work unit is happening at a given time. The algorithms are typically each snippets of code instead of full applications, so someone would need to piece together quite a lot of information.
Of course, if someone is particularly concerned, they can run a jar obfuscator.