idle CPU markets

[Jay Campbell]

>1.  Many such applications want their computation to be highly 
>responsive--  the long turn-around involved in farming your task 
>over a WAN is often prohibitive.  (E.g. real-time graphics.)

Use the right tool for the right job. Cycle sales are useless for most
applications, and forcing a square peg into a round peg will only result in
frustration. There are a gazillion useful outlets for this technology,
though - more pop up all the time. The latest I heard today was OCR .tiff ->
.txt conversion, where the payee can afford (cpu-wise) to toggle all the
settings to the highest (slowest) quality.

>2.  Also many applications that need this kind of power are highly 
>sensitive to inaccuracy or fraud.  A scientific modelling experiment 
>which uses zillions of cycles can be rendered completely worthless 
>if a tiny calculation that had been farmed to Joe Blow is done wrong 
>or is lied about by Joe.

Voting - send the same data to 3+ unrelated machines (if you can afford
redundancy) and accept the 'majority opinion'.

Sanity checking - depends on the algorithms in question; may require human
intervention in many cases, where errors (accidental or not) may not be
easily machine-recognizable.

... just to name a couple of the top of my head.

>3.  Similarly, many such applications are highly confidential.

This is the easy one :) That is to say, solutions to this problem are
already being implemented for other applications.
--
   Jay Campbell                edge at got.net - Operations Manager
   -=-=-=-=-=-=-               Sense Networking, Santa Cruz Node
   Jay at Campbell.net            got.net? PGP MIT KeyID 0xACAE1A89           
 
"On the Information Superhighway, I'm the guy 
  behind you in this morning's traffic jam leaning on his horn."