Message boards :
Technical News :
Blip (Sep 16 2009)
Message board moderation
Previous · 1 · 2 · 3
Author | Message |
---|---|
1mp0£173 Send message Joined: 3 Apr 99 Posts: 8423 Credit: 356,897 RAC: 0 |
Well my options are to accept any type of unit S@H sends. As long as BOINC is capable of selecting the correct software to crunch a unit, and doesn't use APv505 to crunch an APv5 or an APvprevious, for example, my computer's efforts will not have been in vain. Yes, it's possible. The problem is predicting the future. We'd want three "ganged" work types today, but in six months it could be four, or five, or more. Given the limited amount of developer time at the project, which would you prefer, software radar blanking (making more data usable), or a "ganged" application switch? To really do this right, it needs to be done in BOINC as part of the BOINC framework, and grousing at the SETI developers (who are busy) won't necessarily get it on the list of things to do to BOINC. If it was up to me, I'd fix it in the veterinary sense (I'd remove all the switches, and default them "on"). |
Norwich Gadfly Send message Joined: 29 Dec 08 Posts: 100 Credit: 488,414 RAC: 0 |
Well my options are to accept any type of unit S@H sends. As long as BOINC is capable of selecting the correct software to crunch a unit, and doesn't use APv505 to crunch an APv5 or an APvprevious, for example, my computer's efforts will not have been in vain. I'm not asking for it to be done, I was simply questioning the reasoning given in an earlier post that each application needed its own switch. |
W-K 666 Send message Joined: 18 May 99 Posts: 19372 Credit: 40,757,560 RAC: 67 |
I'm not asking for it to be done, I was simply questioning the reasoning given in an earlier post that each application needed its own switch. If the results for the present day application could validate against the results for an older application there wouldn't need to be switches for each application. But at the moment the three AP variants will not validate against each other. Therefore they each have different names AP, AP5 and AP505, as defined by the rules under which BOINC operates, if they were just progressive upgrades of the application then BOINC would only allow, and use, the latest version to process an AP task. We had the same problem when the Seti application went from vanilla Seti to enhanced Seti, the application had to have different names. If need be think of them as different projects all run within the Seti project. So that since we went BOINC Seti has run vanilla Seti, enhanced Seti, enhanced MB Seti, AP, AP5 and AP505. What probably causes most confusion is that unlike the Seti apps that were introduce over a period of years, the AP apps were introduced over a period of weeks. |
Norwich Gadfly Send message Joined: 29 Dec 08 Posts: 100 Credit: 488,414 RAC: 0 |
I'm not asking for it to be done, I was simply questioning the reasoning given in an earlier post that each application needed its own switch. Either this is a non-sequitur, or the information provided in an earlier post, that every work-unit tells the client which version of the software to use, and that the switches just enable the volunteer to accept some work-units and not others, must be wrong. If a work-unit has been crunched using AP say, and the same work has been sent out to a wingman as an AP5 or AP505 unit, then the results are incompatible, so work will have to be re-sent so you end up with 2 compatible sets of results, both AP, or both AP5, or both APv505. If as you imply the switches influence what software to tun for a given work-unit, then how does the client decide what to do when all the switches are set to yes ? |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14679 Credit: 200,643,578 RAC: 874 |
I'm not asking for it to be done, I was simply questioning the reasoning given in an earlier post that each application needed its own switch. The WUs (segments of data recorded at the telescope) are the same. The instructions given by the server - "Process this data with such-and-such an application" - are different: it is the server which tells the BOINC client which (possibly of many) science applications to use. In the case of Astropulse, the different applications - even when working on the same data - produce different results. That's why they don't validate against each other. |
Gundolf Jahn Send message Joined: 19 Sep 00 Posts: 3184 Credit: 446,358 RAC: 0 |
In the case of Astropulse, the different applications - even when working on the same data - produce different results. That's why they don't validate against each other. But that wasn't the question. The question is: why do I need more than one checkbox to say if I want to compute AstroPulse or not (the "other applications" question aside)? WinterKnight wrote: If need be think of them as different projects all run within the Seti project. So that since we went BOINC Seti has run vanilla Seti, enhanced Seti, enhanced MB Seti, AP, AP5 and AP505. Following that logic, there should be 6 switches, not three. And I do know that there's currently no time to realise a change. Gruß, Gundolf |
Josef W. Segur Send message Joined: 30 Oct 99 Posts: 4504 Credit: 1,414,761 RAC: 0 |
In the case of Astropulse, the different applications - even when working on the same data - produce different results. That's why they don't validate against each other. 1. Astropulse v5 work "pays" about 1200 credits, Astropulse v505 about 700. 2. "My host has done v5 work successfully so I'm comfortable with doing more." 3. "v505 is newer, therefore must be better. I don't want any of the old stuff." 4. "I'm using dial-up and know that accepting the new stuff will mean not only half an hour to download the WU but another 15 minutes to get the new application." 5. "This is my computer, I want to control what it's doing." Distributed computing must always keep the psychological factors of thousands of human participants in mind. Giving volunteers full choice of what to accept when there are only 3 possibilities is probably good psychology. Having one choice which is no longer meaningful and missing one choice which is definitely meaningful is probably very bad psychology. WinterKnight wrote:If need be think of them as different projects all run within the Seti project. So that since we went BOINC Seti has run vanilla Seti, enhanced Seti, enhanced MB Seti, AP, AP5 and AP505. Finding the "project_specific_prefs.inc" file and editing the little list of choices to show is certainly easier than designing a change to BOINC server software. It's even easier than Ned Ludd's idea of turning off the choices, as the AppFiltering documentation notes, "currently there is no easy way to cancel it". Joe |
W-K 666 Send message Joined: 18 May 99 Posts: 19372 Credit: 40,757,560 RAC: 67 |
In the case of Astropulse, the different applications - even when working on the same data - produce different results. That's why they don't validate against each other. Tasks to be processed with vanilla Seti and enhanced Seti apps have been done years ago and therefore switches are obselete. If there are any AP tasks still around, some people might not want to do them because they take about twice as long to process as AP505, but still have the same 30 day deadline limitation. This switch is probably redundant. There are probably very few APv5 tasks left, so this sw will probably be redundant next year. Which should then get us back to the nominal situation of choosing Seti enhanced MB and/or AP. And then having to answer the questions "why are the deadlines so different for Seti and AP?" |
Claggy Send message Joined: 5 Jul 99 Posts: 4654 Credit: 47,537,079 RAC: 4 |
Sorry, I didn't realize that the switch hadn't been implemented. I'll figure out how to do so. Now the Astropulse Splitters are online, can we have that Astropulse_v505 switch?, Please. Claggy |
Claggy Send message Joined: 5 Jul 99 Posts: 4654 Credit: 47,537,079 RAC: 4 |
Sorry, I didn't realize that the switch hadn't been implemented. I'll figure out how to do so. Bump, Claggy |
Norwich Gadfly Send message Joined: 29 Dec 08 Posts: 100 Credit: 488,414 RAC: 0 |
Why not just have one Astropulse switch which applies to all Atropulse units being sent out regardless of type ? |
W-K 666 Send message Joined: 18 May 99 Posts: 19372 Credit: 40,757,560 RAC: 67 |
Why not just have one Astropulse switch which applies to all Atropulse units being sent out regardless of type ? The applications have changed, for good reasons, and due to these changes the tasks will not validate if done with different applications. And because of the way BOINC works, it only allows one application per project, the Astropulse versions have to be treated as different projects. |
Norwich Gadfly Send message Joined: 29 Dec 08 Posts: 100 Credit: 488,414 RAC: 0 |
Why not just have one Astropulse switch which applies to all Atropulse units being sent out regardless of type ? How will having different AP switches help ? Currently there's an AP switch, an AP v5 switch and you are proposing an AP v505 switch as well. Let us suppose I as a volunteer have all three options ticked, so I can get units for all 3 AP projects. Surely BOINC must ensure that each of my units gets processed with the appropriate application software, or are you saying it would get its knickers in a twist and process with the wrong software, e.g. a v5 with v505 software ? |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14679 Credit: 200,643,578 RAC: 874 |
Why not just have one Astropulse switch which applies to all Atropulse units being sent out regardless of type ? At the time the multiple switches were set up, it made some sort of sense. I'm willing to help finish off the run just ending, but I don't want to make a long term commitment - you want to get cracking on the new stuff, leave the dregs to people like me. Or something like that. But given that it's now eight-and-a-half months since v505 was installed (10 Jun 2009 18:51:25 UTC - check the Applications page), the whole question is somewhat moot. AP classic and AP v5 are both history, and have been for a long time. Welcome to March 2010. |
©2024 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.