Re: idle CPU markets

[Jay Campbell <edge@got.net>]

>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@got.net - Operations Manager
   -=-=-=-=-=-=-               Sense Networking, Santa Cruz Node
   Jay@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."