Jim Kent wrote:

On Tue, 12 Aug 2003 11:08:06 +0200, "FalconFly"
<falconfly@ewetel.net> wrote:

You have about 48 hours (max.) to return them, in order to get the
Results into the scientific Database.

[...]

Your assertion about the 48 hour liimit to get into the scientific database is a bit hard to believe, because a lot of people are still running machines that take that long to do a single unit.  If these are all invalid that effort is utterly pointless and a waste of their
 time, electricity, and all the work unit management effort at SETI that supports these users.

Trying to avoid getting lost in too much detail...
(But failing badly! (:-O))

The conclusion is:

In short, you gamble on how quickly others return their WUs compared to yourself, and how large a WU pool size s@h maintain. Gamble on too long to get your WU result back to the server and that extra result for the WU is discarded. You still get credited with one more point for your WUs completed statistic.


The s@h servers are very unlikely to be offline for more than 2 days (some disaster over a weekend to be fixed Monday morning), so it is pointless having more than 2 days of cache.

(And BIG caches make the situation harder for the s@h servers (:-))

Until s@h can be a little more open about utilisation, if you need a larger cache due to being offline, perhaps you should look at other distributed computing projects that can tolerate long delays for the results and better utilise your power.




In further explanation, my 'best guess' on s@h's current operation:

(Look up the earlier threads on cache sizes...)


The s@h servers send out in one gulp 3 or 4 (or 5 or more) copies of a particular WU.

Some time later, an 'offline' server job is run which checks for a minimum of 3 results for each WU in the 'server pool'. If that WU has got 3 or more results, then it is removed from the WU 'pool', otherwise it is left there for further copies of it to be sent to more users.


Now, in the real world, some users return their results in less than two hours after receiving the WU from the s@h server. Others likely have slower machines or delay things further by the size of their WU caching and WU results caching.

Your WU result, to be scientifically useful, is in a race to get back to the s@h server before that WU is deleted from the s@h server WU pool.

The time delay before a WU is deleted from the pool is a minimum of how long it takes for 3 results to be returned. The maximum time is a combination of the size of the WU pool and how quickly the WUs are replaced by new WUs from the tape splitters. The number of WUs swallowed up by user caches also complicates this story...

There have been a number of (old) authorative posts to say that a WU stays in the pool for less than one month. With the increase in active users, and faster machines, and the use of caching, that time may now be less if the s@h tape splitters can supply new WUs quickly enough.

s@h list on their site that the average WU processing time is 8hr 57min 48.9sec over the last 24 hours.

See:
http://setiathome.ssl.berkeley.edu/totals.html

Unfortunately, there are no direct stats indicating the churn rate on the WU pool, or the pool size, or the proportion of those WUs distributed to users. Hence, the useful lifetime for a WU is guesswork.

Some information is sampled by:
http://www.roving-mouse.com/setiathome/



I run with a very small cache to try to keep the results useful. Another project gets my spare cycles if s@h can't keep their servers online.

Keep crunchin'
Martin