"Krokr" <n/a> wrote in message
news:40e136c2$0$275$cc9e4d1f@news-text.dial.pipex.com...

Thanks for posting the FAQ, it was quite interesting.

The problem of Olli in 1999 with the 'patched' code raised some questions
for me, as the SETI team seemed to be happy to provide less efficient
code as they were unable to increase the rate of WU creation/results:-
   "The effect of a faster client on this bottleneck
    would be a higher rate of rejected connections
    and a lower system efficiency".
As a Capacity Planner, for more years than I care to remember, this is a
strange approach to 'system efficiency'. If you make the client code
twice as efficient but can't support the results coming back twice as
fast, then give them out only at a rate you can support. You can give the
users the same WU's and let them have back half their CPU cycles -
nothing forces you to keep them fully occupied!  CPU cycles are a
resource and it is NEVER a good idea to waste a resource.

My worry is that I would like to use my spare CPU cycles efficiently to
support several good causes, but if SETI(or any other project) is going
to 'waste' them then perhaps other projects should get higher priority.
In light of the new BOINC initiative is there going to be any focus on
the code efficiency? I've already noticed a significant increase in the
processing per WU with BOINC, and hope that this will be addressed.

However, this is likely to be a problem for all the distributed projects,
as they will all feel that time on their part to make the code more
efficient is a 'cost' to them, whereas the users CPU is a 'free'
resource.  Perhaps if users are willing to contribute on the coding side
then projects need to consider how to manage such support? Anyone have
any thoughts?

I think you are most likely correct in the 1st half of your last paragraph.
But I believe SAH1 inadvertantly developed into a different scenario.
In SAH's case, IIRC, they were the second 'mainsteam DC proj (after GIMPS),
and were not prepared for the high response rate. The huge influx of
participants and the reality of Moore's Law, along w/the explosive growth in
'consumer' access to the web & high speed comm, all contributed to the
abundance of resources in relation to work available. Also, Berkeley has to
compete with the astronomical community at-large, for 'dedicated' sky
viewing time, instead of only passively piggy-backing upon other
researchers' viewing events. This was exasperated by the 'dragging on' of
SAH1, due to various probs.

While your premise of 'giving back' unused clock cycles, when work is not
available, is a noble and just cause (and is incorporated into BOINC), many
DC'ers would probably not except this. Many DC'ers I'm familiar with, view
DC as a competitive sport. Just take a look at the disgruntlement w/the
current lack-of-work periods, and the resulting uproar. Without a continous
pool of work, many will not want to run the project. And there's absolutely
nothing wrong with this. DC is a hobby, and therefore FUN, should, IMO, be
an intrinsic ingredient. I would suspect a fair amount of DC'ers will not
stay on a dedicated project, if the work available is sporadic.

As for making source code available, I can't check the SAH2 site, 'cuz it's
down again, but I thought I saw the code was available. I don't remember if
this was the proj client code, BOINC platform code, or both. Pls don't
take this as 'an absolute'. I can't verify this, ATM. I "thought" I saw a
link, in passing.

If I were the proj mgr, I'd be extremely wary of allowing public access to
the code. SAH1 was rife w/cheating. This not only causes bad PR and
disillusionment, but worst, can compromise the integrity of the science, and
therefore, the project itself. BOINC appears to have addressed the cheating
issue pretty well, with the 3 matching results technique, along with only
sending 3 WU copies at a time, and tracking the return from thier specific
machine. But I would still be concerned w/maintaining the integrity of the
project, foremost, if it were my proj.

JMO's.
-- 
Strat