On Thu, 26 Jan 2006 18:34:32 GMT, Johan Plane <johan.plane@telia.com>
wrote:

Well, i started with classic in summer of '99, and I do remember the bad
times also. However, the longer the project as a whole is going on the
tougher demands Berkeley will have to meet. What I find disturbing is that
even though the transition from classic to BOINC was done over a
substantial time, the architecture of the new system wasn't made better

>from scratch. Knowing the problems with classic, one would have hoped that

they had learned the lessons and designed a system with a high grade of
redundancy, instead of starting to plan for that now when the system is in
full use. That is a slip that I guess would only be tolerated in academical
environments and any other ad hoc governed businesses. Technical strategy
is the keyword missing.

Well... let's see on the BOINC-system:
1; Can run multiple scheduling/feeder-servers, SETI@Home was for a
short time running 2, when moved from old server to new with 3x as
many cpu's.
2; Can run multiple upload-servers, example CPDN has 2 in UK and 1 in
Switzerland.
3; Can run multiple download-servers, example Einstein@home has 5
different spread around the world.
4; Can run multiple Transitioners, SETI@Home runs 6 spread across 3
servers.
5; Can run multiple Validators, SETI@Home currently runs 4, these has
been spread across multiple servers earlier.
6; Can run multiple Assimilators, SETI@Home currently runs 4, these
has been spread across multiple servers earlier.
7; Can run multiple work-generators, SETI@Home currently runs 6 spread
across 6 different servers, has earlier run 7.
8; Can run multiple file-deleters, SETI@Home currently runs 4, these
has been spread across multiple servers earlier.
9; Can run multiple db-purgers.
10; Can run multiple web-servers, SETI@Home currently runs 2 servers.
11; A project can AFAIK only have one BOINC "master"-database, but can
run replica-servers so example stats and so on is generated from the
replica. SETI@Home earlier ran a replica-server, but this was not
powerful enough to keep up with increased demand.


So, looking from the BOINC-standpoint, a project can run as many
instances of the backend-services across as many servers they think is
neccessary, and by this getting excellent redundancy. But, while it's
no problem to configure the BOINC-software, the projects must also
have enough money to buy these servers...

When it comes to SETI@Home, they needs another server that can acts as
replica-database, but they don't have enough money to buy this server.
Therefore, they're stuck doing weekly outages for backing-up the
database instead.


Despite of not having enough money to buy a new
replica-database-server, SETI@Home according to Technical News is
pushing-out 1.2M results/day. When also knows the current
SETI@Home-recorder at Arecibo at max can record 271k wu/day, and
SETI@Home is sending-out 4 results/wu and for getting the science done
4 results/wu is actually on the high-end so no point to increase this,
they're currently running on 110% of Arecibo's max record-capasity.

Meaning, the current bottleneck is not the SETI@Home servers and
ocassional planned or unplanned outages, but instead Arecibo, so if
Seti_Enhanced isn't "soon" released, you'll be out of work regardless
of SETI@Home having outages or not.

-- 
"I make so many mistakes. But then just think of all the mistakes
I don't make, although I might."