Choosing to run only ABP work?
11 Jan 2010 20:21:39 UTC
Topic 194719
(moderation:
A few days ago, I was "nosing about" looking for performance data to help decide on my next PC build. One of the participants recent work history showed "aborted" for the GW tasks and "successful" for the ABP tasks. Somehow, his GW tasks were getting aborted before any time was spent processing them.
On looking at other users, I noticed that the credit granted for an hour of running ABP tasks seems significantly greater than for the same time spent running GW tasks.
Is "selective processing" a common procedure? Is it an "accepted procedure?" Is there a better approach to inflating one's RAC than "just tossing assigned work?"
Stan
Choosing to run only ABP work?
)
Well, analyzing the LIGO GW detector data is the "main business" of Einstein@Home, that is why the web-interface does not allow to opt-out of the GW search, only to opt-out of the ABP search.
Cheers
HB
So do you think it would be
)
So do you think it would be reasonable to penalize participants who selectively abort GW units?
RE: So do you think it
)
I don't think it's worth the effort, since there is only very little bandwidth used when the data files for GW tasks are present on the host. And since the daily quota is reduced with each abort, there's a means already to prevent excessive abuse.
Moreover, judging from other threads on this forum, I think that for many users is not "cherry picking" the reason to abort, but stalling GW tasks.
Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
RE: So do you think it
)
Let's not forget that we are talking about volunteers who donate precious resources to the project. I can't speak for the project management but from what I've experienced, "penanlizing" users would be against the spirit in which this project is run.
Users have to understand, tho, that the project has certain goals, some primary, some secondary. For the moment, I think the maximum number of WUs per day per core is enough to keep people from canceling too many WUs.
If nevertheless this should turn into a real problem, instead of "penalizing" anyone, a credit adjustment to level the playing field between the searches would be the "friendlier" solution.
CU
HB
RE: RE: So do you think
)
Participants making posts proposing that people doing things they don't like should be penalized are a regular feature over at SETI@home. One of the joys I take in participating here at Einstein is the merciful freedom from that sort of thing.
Anyway, user selection of which units to process between major types would quite likely be productive if the scores were properly adjusted. In any case in which the processing code differs substantially, it is quite likely that one processor architecture or another, or one consistent configuration versus another, will have comparative advantage. Just as in foreign trade among nations, everyone benefits if productive facilities are dedicated to their best comparative advantage.
I do agree that in recent conditions ABP is probably overcompensated relative to GW. I shall confess that this was a factor in my own procrastination in removing my ap_info.xml file, which has been getting me a pure diet of ABP for some weeks. This is coming to an end, as the available supply of ABP provided to my hosts has dropped off too much, and the first of my three primary hosts switched to default operation yesterday.
RE: And since the daily
)
I don't think user aborts reduce the daily tasks per core value, correct me if I'm wrong.
As to the original question, like Bikeman said, adjusting the credit fairly between the apps would be best. This is of course hard to do due to the varying runtime of GW tasks. Any penalties for cherry-picking would be wrong.
It seems to me that S5R6 tasks are more likely to run long. An S5R5 task taking over six hours on my Q9550 was a rarity and they always were at the expected runtime peak. With S5R6 it's commonplace to have a 6+ hour task credited perhaps 190 (~203 max). An ABP1 task takes/took less than five hours and gets 250. With that said, I should also say that I have very little interest in credit gained other than observing milestones reached to note how much work has been done.
Thanks to all for insightful
)
Thanks to all for insightful comments.
I had not considered any "stalled GW tasks" as I've not seen any among the 100 or so tasks I struggle through each day. But I have a limited range of OS versions and processor types upon which to base the observation.
The daily quota issue did not seem to affect the "curious sample" that I looked at. Successful ABP runs seems to counteract the abort quota reduction.
In the end, equitable allocation of credit seems the obvious solution since it supports the project's key goal. (I used the term "solution" on the assumption that aborting otherwise good tasks is a problem. I think it would be a problem if the practice were widespread. Apparently it is not so common ... yet. I hope that asking the question does not spur more such aborts.)
Such aborts are just a symptom of an equitable credit problem, indicating that the imbalance is extreme enough to spur some reaction. Were such aborts to become more common, then the project would likely see the need to balance credit more equitably. Meanwhile, using credit/time information from many completed tasks may continue to be a viable method for setting credit rates.
Stan
One of the main problems with
)
One of the main problems with assigning credit for ABP1 was the variation between Apps on different platforms, that was much larger than e.g. for the GW search. We had to adjust the credit to get it right on average; such that for people on one end of the spectrum it was advantageous to run only ABP1 tasks.
This variation should be a lot smaller with ABP2, and we changed the code such that we can easily adapt the credit granted for ABP2 WUs basically anytime.
I hope (and will work on) that with ABP2 people won't feel a need for just running ABP for getting more credit.
The funding for Einstein@home is to a large part bound to the GW search, so we can't let people 'officially' opt out on that.
BM
BM
RE: One of the main
)
Thank you, Bernd. Sounds like you are on top of this.
With so much "good science" to address, you should not need to spend much time dealing with ancillary issues for which the only benefit is keeping participants participating. Since quite the majority of us (from my sample of 4 or 5 high value participants) do not circumvent the mostly random work selection while we keep on chugging out the analyses, there may be little loss from those few exceptions.
Stan