Settings for backup project?

hm
hm
Joined: 15 May 05
Posts: 10
Credit: 16825087
RAC: 0
Topic 189503

What settings do I use so that BOINC will run einstein all the time, but if somehow einstein goes down and my client is unable to obtain new work it will, only in that case, switch to another project for one work units worth of work? Anyway to do this?

John McLeod VII
John McLeod VII
Moderator
Joined: 10 Nov 04
Posts: 547
Credit: 632255
RAC: 0

Settings for backup project?

Almost.

Set your primary project to have a very large resource share (1,000,000) for example, and your backup to have a very small resource shre (0.00000001) for example. Then let this crunch through the first few WUs of your backup project to set (the larger your connect to every X setting, the more WUs of the backup project will be required). After this, you should see WUs from the backup project once every couple of decades unless the primary is out of work. This only works correctly with 4.35 and later BOINC versions.

Heffed
Heffed
Joined: 18 Jan 05
Posts: 257
Credit: 12368
RAC: 0

Pssst, hm... Correct your

Pssst, hm...

Correct your sig. It stretches the page. ;)

Ken Vogt
Ken Vogt
Joined: 18 Jan 05
Posts: 41
Credit: 321783
RAC: 0

John, This is a

John,

This is a wonderfully clever and cool idea, IMO. :)

When I tried it I kept the default 100 share for my primary and something such as 0.00000000001 for secondary and I got a floating point error from BOINCview & couldn't get it to update to safer values. Trying BOINC Manager caused a dozen or so instances of BM to open. After closing them from the tray I was able to get down to a single instance of BM and got it to update to a 100/25 split.

Both BM and BV are now happy.

I don't know if the FP error would also happen using your values of 1000000/0.00000001, or if there is some safe ratio that would not cause an error, and still permit the secondary to run only very rarely?

Ken

Vladimir Zarkov
Vladimir Zarkov
Joined: 27 Feb 05
Posts: 66
Credit: 4876895
RAC: 0

Einstein@Home is the only

Einstein@Home is the only project I'm really interested in, but to be on the safe side my PC crunches for SETI too - 400/100. This ratio is acceptable for me, as I want to do a little something for SETI as well. :)

Ocean Archer
Ocean Archer
Joined: 18 Jan 05
Posts: 92
Credit: 368644
RAC: 0

If I was going to setup my

If I was going to setup my machine to run E@H almost exclusively, with S@H as my fallback backup, I'd personally set my shares to 990 and 010 respectively, and adjust my work cache to 2.0 days. That should allow E@H to run freely and only receive a packet from S@H when Einstein was down for an extended period of time (weekend outage or worse). >> The preceeding was totally MHO


If I've lived this long - I gotta be that old!

Paul D. Buck
Paul D. Buck
Joined: 17 Jan 05
Posts: 754
Credit: 5385205
RAC: 0

You can also "fiddle" with

You can also "fiddle" with the cache size settings, though current wisdom is to not get them too high. In the next release we are expecting code that will, as JM VII has told us will allow us to "converge" on a better time to complete value than we are currently experiencing.

This is part of the growth of the system and an interesting sign of maturity ... we are working on stuff that makes the system run better and not on just those issues to make it work at all ...

Ken Vogt
Ken Vogt
Joined: 18 Jan 05
Posts: 41
Credit: 321783
RAC: 0

Thanks for the reply,

Thanks for the reply, Paul.

I've currently settled on running with these shares:

Einstein@Home=100
predictor=.01

This avoids floating point problems in the guis and gives
a long enough continuous run to E@H for practical purposes.
If I interpret BoincView right, this is 865 days, so if E@H
servers run continuously for that long, I'll be happy
to do another predictor WU. :)

It is working exactly as John said: two predictor WUs came down
initially (when the share was 100/25); the first has now finished,
and the second is presumably waiting until close to its deadline.
All the rest of the time it has been happily crunching E@H.

Predictor is very good as a backup app in this setup: quick WUs
with long deadlines. I wouldn't recommend CPDN, for example. :)

Paul, the thing I like best about this is it does allow you to
use a very small cache setting (.1 for me) without worrying about being
immediately out of work when a long outage hits: There will
almost always be work on one of the two projects.

Ken

Paul D. Buck
Paul D. Buck
Joined: 17 Jan 05
Posts: 754
Credit: 5385205
RAC: 0

RE: Paul, the thing I like

Quote:
Paul, the thing I like best about this is it does allow you to
use a very small cache setting (.1 for me) without worrying about being
immediately out of work when a long outage hits: There will
almost always be work on one of the two projects.

Yes. Then there was "black thursday" ... when we were down to Predictor@Home ... oddly enough when a couple of the project struggled back to life, if I recall correctly PPAH also went down for a day ...

I really like feeling like I am a part of great things. I don't object to a small project list or those that want to contribute most to just one project. I just point out that contrary to claims of SETI@Home Classic not having outages are just plain wrong. I redid the 4-5 years of techincal news off the old site and there were plenty of multi-day and week long outages... and this is still a risk.

Small problems we rarely noticed, because the fanatics (like me) were using long caches and we had little to no visibility into the behavior of the project on the server side. The current visibility where you can SEE the interactions and the failures make it SEEM like we have major problems.

Anyway, I am glad you have a configuration that works for you ... I probably should discuss this better in the set up area ... I will try to figure out how and where ...

gravywavy
gravywavy
Joined: 22 Jan 05
Posts: 392
Credit: 68962
RAC: 0

RE: Predictor is very good

Message 13889 in response to message 13887

Quote:
Predictor is very good as a backup app in this setup: quick WUs
with long deadlines. I wouldn't recommend CPDN, for example. :)

cpdn is a good backup against a different failure mode.

Where a project like predictor (small wu soon complete)
is ideal to protect you against failure of the primary
project, and network failure close to the primary project,
it is no good to protect you against prolonged network
failure that occurs near near you.

If your phone line goes down for a week, and takes your
ADSL connectiuon with it, will you pack up BOINC for that
week, or do you want to go on doing work that is useful
to someone?

It does happen; sometimes to a whole city, as New York
discovered some time ago now...

Solution: run cpdn as a low priority. When your cpdn wu
downloads, let it run for a day or so with a large
resource share (50% or more), to see what the estimated
cpu time to completion is. On a 700MHz machine it is
about 3000 hours, for example. There are about 7000
hours till the cpdn deadline. So I'd give it 3/7th of
machine resources, and the 3000 run time will fit
nicely into the actual deadline.

On a faster machine the fraction devoted to cpdn would
be correspondingly lower, of course. You may well
not feel happy giving 3/7 the resource to a backup,
but might be happier if it was more like 1/10th the
resource as may be the case on a faster machine

Then if you get cut off from the outside for a long
time, your machine will crunch cpdn intensively while
it has nothing else to do. Whe the other projects
come back, providing you use the latest verison of
the BOINC client, it will then give cpdn a rest
till the other projects make up lost time. The only
long term loss to those projects would be any wu that
timed out during your network problems.

So, for me the ideal backstop has two projects,

1) cpdn, resilience against local network problems,
protects against all circumstances except where
those problems occur near the turn round of the
cpdn wu; resource share calc as above

2) orbit@home (when available) or Predictor (now)
to offer resilience against remote server failure,
resource share around 1/10000

If the resource share calculated for cpdn is too
high for your comfort, then you may prefer to leave
yourself unprotected against local network failure,
as always you are a volunteer here and it is entirely
your choice. However, cpdn is a project that may be
dealing with the future habitablility of our planet, so
I personally hope you could see the time given to cpdn
as being more than merely a 'filler'.

~~gravywavy

Ken Vogt
Ken Vogt
Joined: 18 Jan 05
Posts: 41
Credit: 321783
RAC: 0

Paul and River, I

Message 13890 in response to message 13889

Paul and River,

I certainly don't have anything against CPDN or predictor! :)
And I certainly agree that the best general strategy is multiple projects
with roughly comparable shares.

Partly my post was in response to hm's original post looking for a backup
specifically to E@H; also, our team in very competitive, and ATM we only do E@H.
They would kill me if they thought I was doing a non-BABB project, no matter how
worthy! Just kidding, but I do crunch for the team.

In fact, I've thought of another situation where some variant of this backup
strategy might be useful:

Some posts over at orbit@home suggest dedicating a computer to it during alpha
so as to more easily isolate any initial problems. But one easily foreseeable
problem is server outages, so I plan to run o@h at 10000 to 1 with E@H on one
machine. I admit this is not complete isolation, but I feel the BOINC platform
is robust enough to handle the minimal switching this would entail.
I expect most people running the less mainstream alpha projects already run
multiple projects, so this strategy would be irrelevant for them.

We will have a BABB team for o@h as well, and my main box will run o@h and E@H
about equally, so I can be of help to most of my teammates, who will do the same.

In conclusion, I'm sorry if I implied this should be a general strategy;
if it may be useful in certain limited situations, such as River mentions
with CPDN; and those I've described, I'm glad.

Ken

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.