Review my startup - Plura Processing: Web Traffic = Grid Computer

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.

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.

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.

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.

---

"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)

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)

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. 

nice indeed ;P

Also, what is the average CPU percentage your developers run on their clients systems?

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.