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.
I am cool with your strategy, I just want to make sure that the good and bad are equally represented ... :)
So, my only point was to say that there is a danger. I find it tedious when some get all fanatical when SETI@Home goes down for whatever reason, and, panic sets in and we get all the comparisons to Classic. A project which, as we all know, never experienced a days outage in its entire history. But I digress ...
As you say, BOINC is robust enough that we can implement strategies like this with a reasonable expectation that they will work ...
... the best general strategy is multiple projects
with roughly comparable shares...
my point is more that people should choose their own strategy out of an informed choice. A general strategy, to my mind, is ideal to get a newcomer off the ground but can then be tweaked later to suit their individual tastes. Some of us (yes, I am one) get more joy out of the tweaking than out of the actual work... Others will install a general strategy then never adjust it, enjoying the screensaver, or their stats, or whatever.
We are all volunteers here and if we are not getting what we want out of donating our machine cycles we will sooner or later get fed up and depart.
Quote:
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
Every motive that keeps you donating is a good one.
That is what I mean about differing motives, personally (at least for now) I am not at all bothered by my team stats, just joined it because it was there...
If the reason for avoiding CPDN is specifically a team thing, could you set up your team on CPDN and start making BABB get noticed there too?
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
Every motive that keeps you donating is a good one.
That is what I mean about differing motives, personally (at least for now) I am not at all bothered by my team stats, just joined it because it was there...
If the reason for avoiding CPDN is specifically a team thing, could you set up your team on CPDN and start making BABB get noticed there too?
There is a good reason to consider it ... :)
On average, CPDN give more credit per second than other projects. Just a thought ... :)
If the reason for avoiding CPDN is specifically a team thing, could you set up your team on CPDN and start making BABB get noticed there too?
River,
Sorry so long replying. The reason I mentioned avoiding CPDN in this strategy was becuase of the length of running a full model. If you used CPDN as the secondary, even a short server outage would commit you to running a CPDN model up until its deadline, at least as I understand it.
Dont' get me wrong, I like CPDN, before it BOINCed and E@H started I was proud to run several models that contributed to the Nature paper; closest I'll ever get to that august journal. :) But hm's original premise was that he only wanted to run E@H, and in this scenario, seti or Predictor or LHC@Home say, would--I sure could be wrong?--be a better extreme low priority backup than CPDN, since that would get you back to full time E@H crunching quicker?
We do in fact have BABB teams for E@H and o@h, and probably soon LHC@Home and maybe PlanetQuest, but since the "BABB" name is intellectual property of The Bad Astronomer, we must ask him for permission to use that name for our teams. I've posted over there that, subject to that condition, anyone interested in a BABB team for any BOINC project is welcome to start one. It is an astronomy board however, so our project bias is somewhat natural?
In conclusion, I love BOINC, will run all three BABB team projects with reasonable shares and am very sorry if I seemed to diss CPDN. :)
If you have a super lopsided shares bucause you wanted to do almost none of the secondary project you should pick a project like Predictor@Home which has real short work units. Then it will not matter that much till your project comes back.
But, I hate to say this, this is really swimming against the tide folks...
I am not saying you should not be able to elect to run one and only one project. But, the system is intended to be BALANCED among several projects. ... I know, broken record ...
There are two times that I can think of that CPDN would be moved from the backup project to the main project.
1) When Einstein is out of work
2) When the deadline of the CPDN WU is within the time needed to complete the WU.
Jim
Quote:
River,
Sorry so long replying. The reason I mentioned avoiding CPDN in this strategy was becuase of the length of running a full model. If you used CPDN as the secondary, even a short server outage would commit you to running a CPDN model up until its deadline, at least as I understand it.
I quite agree, and it would indeed be some months before BOINC would return to CPDN after the Einstein@Home server was restored. But the point is, it would eventually return to CPDN in time to meet the deadline, and because CPDN models take so long, would have to work continuously on CPDN for a long time--weeks at least--to finish the one WU it started.
This is contrary to the wish of the OP in wanting Einstein@Home to yield only in case of server failure. Of course, one could abort the CPDN unit once the E@H server came back up, but that would be anti-BOINC, and also conflict with the OPs desire to do useful work during outages.
So I completely agree with Paul that predictor or LHC@Home or orbit are better choices if one wanted to employ this extreme strategy---in fact, that is exactly what I said in my first post about this! :) And in fact I used Predictor to test the strategy, and it worked just as advertised.
I only mentioned CPDN as an example of a project, for the above reason, that I thought would not be so good for this particular strategy, and I in no way intended to diss it! :)
I apologize because I have so much trouble communicating in this medium; please believe me: I love BOINC and I do run two, soon three, projects at comparable shares. :)
I do have to disagree with Paul on enforcing multi-project use of BOINC; but I'm sure this has been discussed elsewhere.
I do have to disagree with Paul on enforcing multi-project use of BOINC; but I'm sure this has been discussed elsewhere.
Oh my yes... :)
I actually only object to the practice where the person elects it and then is unwilling to accept the consequences. Which is all I try to point out. If you want to only do one project, be my guest ... :)
But do NOT complain about the idle computer. Sorry, but that is a possible consequence. This debate happens on the SETI@Home side ... right now, ther is a problem. Ok, some people are running out of work, or have some other problem ... well ... your choice ... and oh, by the way, I have over 30 work units completed and waiting to upload ... and rising ...
I think you are doing a wonderful job communicating in this medium. In fact, you are probably doing a better job at it than some of us native english speakers. LOL
I wasn't really trying to argue for or against CPDN in this case, I was just trying to give two circumstances under which CPDN would be moved from the backup project to the main project. I agree with you that aborting the CPDN WU just so one could run a different project would be anti-BOINC.
I know Paul already commented on this, but I also wanted to comment. Paul was not advocating that people should be required to run more than one project, he was just stating that it is his opinion that they should and that the spirit behind BOINC was to spread the work out between projects.
I hope to hear from you again on these boards. :)
Jim
Quote:
Jim,
I quite agree, and it would indeed be some months before BOINC would return to CPDN after the Einstein@Home server was restored. But the point is, it would eventually return to CPDN in time to meet the deadline, and because CPDN models take so long, would have to work continuously on CPDN for a long time--weeks at least--to finish the one WU it started.
This is contrary to the wish of the OP in wanting Einstein@Home to yield only in case of server failure. Of course, one could abort the CPDN unit once the E@H server came back up, but that would be anti-BOINC, and also conflict with the OPs desire to do useful work during outages.
So I completely agree with Paul that predictor or LHC@Home or orbit are better choices if one wanted to employ this extreme strategy---in fact, that is exactly what I said in my first post about this! :) And in fact I used Predictor to test the strategy, and it worked just as advertised.
I only mentioned CPDN as an example of a project, for the above reason, that I thought would not be so good for this particular strategy, and I in no way intended to diss it! :)
I apologize because I have so much trouble communicating in this medium; please believe me: I love BOINC and I do run two, soon three, projects at comparable shares. :)
I do have to disagree with Paul on enforcing multi-project use of BOINC; but I'm sure this has been discussed elsewhere.
RE: In conclusion, I'm
)
I am cool with your strategy, I just want to make sure that the good and bad are equally represented ... :)
So, my only point was to say that there is a danger. I find it tedious when some get all fanatical when SETI@Home goes down for whatever reason, and, panic sets in and we get all the comparisons to Classic. A project which, as we all know, never experienced a days outage in its entire history. But I digress ...
As you say, BOINC is robust enough that we can implement strategies like this with a reasonable expectation that they will work ...
RE: ... the best general
)
my point is more that people should choose their own strategy out of an informed choice. A general strategy, to my mind, is ideal to get a newcomer off the ground but can then be tweaked later to suit their individual tastes. Some of us (yes, I am one) get more joy out of the tweaking than out of the actual work... Others will install a general strategy then never adjust it, enjoying the screensaver, or their stats, or whatever.
We are all volunteers here and if we are not getting what we want out of donating our machine cycles we will sooner or later get fed up and depart.
Every motive that keeps you donating is a good one.
That is what I mean about differing motives, personally (at least for now) I am not at all bothered by my team stats, just joined it because it was there...
If the reason for avoiding CPDN is specifically a team thing, could you set up your team on CPDN and start making BABB get noticed there too?
~~gravywavy
RE: RE: our team in very
)
There is a good reason to consider it ... :)
On average, CPDN give more credit per second than other projects. Just a thought ... :)
RE: If the reason for
)
River,
Sorry so long replying. The reason I mentioned avoiding CPDN in this strategy was becuase of the length of running a full model. If you used CPDN as the secondary, even a short server outage would commit you to running a CPDN model up until its deadline, at least as I understand it.
Dont' get me wrong, I like CPDN, before it BOINCed and E@H started I was proud to run several models that contributed to the Nature paper; closest I'll ever get to that august journal. :) But hm's original premise was that he only wanted to run E@H, and in this scenario, seti or Predictor or LHC@Home say, would--I sure could be wrong?--be a better extreme low priority backup than CPDN, since that would get you back to full time E@H crunching quicker?
We do in fact have BABB teams for E@H and o@h, and probably soon LHC@Home and maybe PlanetQuest, but since the "BABB" name is intellectual property of The Bad Astronomer, we must ask him for permission to use that name for our teams. I've posted over there that, subject to that condition, anyone interested in a BABB team for any BOINC project is welcome to start one. It is an astronomy board however, so our project bias is somewhat natural?
In conclusion, I love BOINC, will run all three BABB team projects with reasonable shares and am very sorry if I seemed to diss CPDN. :)
Ken
If you have a super lopsided
)
If you have a super lopsided shares bucause you wanted to do almost none of the secondary project you should pick a project like Predictor@Home which has real short work units. Then it will not matter that much till your project comes back.
But, I hate to say this, this is really swimming against the tide folks...
I am not saying you should not be able to elect to run one and only one project. But, the system is intended to be BALANCED among several projects. ... I know, broken record ...
There are two times that I
)
There are two times that I can think of that CPDN would be moved from the backup project to the main project.
1) When Einstein is out of work
2) When the deadline of the CPDN WU is within the time needed to complete the WU.
Jim
Jim
Jim, I quite agree, and it
)
Jim,
I quite agree, and it would indeed be some months before BOINC would return to CPDN after the Einstein@Home server was restored. But the point is, it would eventually return to CPDN in time to meet the deadline, and because CPDN models take so long, would have to work continuously on CPDN for a long time--weeks at least--to finish the one WU it started.
This is contrary to the wish of the OP in wanting Einstein@Home to yield only in case of server failure. Of course, one could abort the CPDN unit once the E@H server came back up, but that would be anti-BOINC, and also conflict with the OPs desire to do useful work during outages.
So I completely agree with Paul that predictor or LHC@Home or orbit are better choices if one wanted to employ this extreme strategy---in fact, that is exactly what I said in my first post about this! :) And in fact I used Predictor to test the strategy, and it worked just as advertised.
I only mentioned CPDN as an example of a project, for the above reason, that I thought would not be so good for this particular strategy, and I in no way intended to diss it! :)
I apologize because I have so much trouble communicating in this medium; please believe me: I love BOINC and I do run two, soon three, projects at comparable shares. :)
I do have to disagree with Paul on enforcing multi-project use of BOINC; but I'm sure this has been discussed elsewhere.
Ken
RE: I do have to disagree
)
Oh my yes... :)
I actually only object to the practice where the person elects it and then is unwilling to accept the consequences. Which is all I try to point out. If you want to only do one project, be my guest ... :)
But do NOT complain about the idle computer. Sorry, but that is a possible consequence. This debate happens on the SETI@Home side ... right now, ther is a problem. Ok, some people are running out of work, or have some other problem ... well ... your choice ... and oh, by the way, I have over 30 work units completed and waiting to upload ... and rising ...
RE: I do have to disagree
)
Shhh! Enforcement is a black operations department of the Wiki team. But I've said to much already... ;)
Ken, I think you are
)
Ken,
I think you are doing a wonderful job communicating in this medium. In fact, you are probably doing a better job at it than some of us native english speakers. LOL
I wasn't really trying to argue for or against CPDN in this case, I was just trying to give two circumstances under which CPDN would be moved from the backup project to the main project. I agree with you that aborting the CPDN WU just so one could run a different project would be anti-BOINC.
I know Paul already commented on this, but I also wanted to comment. Paul was not advocating that people should be required to run more than one project, he was just stating that it is his opinion that they should and that the spirit behind BOINC was to spread the work out between projects.
I hope to hear from you again on these boards. :)
Jim
Jim