Blip (Sep 16 2009)


log in

Advanced search

Message boards : Technical News : Blip (Sep 16 2009)

Previous · 1 · 2 · 3
Author Message
1mp0£173
Volunteer tester
Send message
Joined: 3 Apr 99
Posts: 8423
Credit: 356,897
RAC: 0
United States
Message 943803 - Posted: 30 Oct 2009, 3:59:38 UTC - in response to Message 943737.

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.

BOINC takes care of keeping the applications straight, so there is no danger of losing credit because BOINC used the wrong application.



As I understand it, the three OUTGOING file formats are different, that is why there were two switches to start with!


Sorry I cannot follow that logic. Whatever type of work unit the server sends to be crunched, it has to be able to accept the file format produced by the crunching software. This would be true if volunteers did not have switches to control what types of work-unit to crunch. So it would be possible to have one switch to control several work unit types.

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
Avatar
Send message
Joined: 29 Dec 08
Posts: 100
Credit: 488,414
RAC: 0
United Kingdom
Message 943826 - Posted: 30 Oct 2009, 9:39:40 UTC - in response to Message 943803.

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.

BOINC takes care of keeping the applications straight, so there is no danger of losing credit because BOINC used the wrong application.



As I understand it, the three OUTGOING file formats are different, that is why there were two switches to start with!


Sorry I cannot follow that logic. Whatever type of work unit the server sends to be crunched, it has to be able to accept the file format produced by the crunching software. This would be true if volunteers did not have switches to control what types of work-unit to crunch. So it would be possible to have one switch to control several work unit types.

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").

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.

____________

WinterKnight
Volunteer tester
Send message
Joined: 18 May 99
Posts: 8219
Credit: 21,809,192
RAC: 11,864
United Kingdom
Message 943866 - Posted: 30 Oct 2009, 15:16:09 UTC - in response to Message 943826.

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
Avatar
Send message
Joined: 29 Dec 08
Posts: 100
Credit: 488,414
RAC: 0
United Kingdom
Message 943874 - Posted: 30 Oct 2009, 16:12:18 UTC - in response to Message 943866.

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.


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
Volunteer tester
Send message
Joined: 4 Jul 99
Posts: 8275
Credit: 44,971,913
RAC: 13,803
United Kingdom
Message 943890 - Posted: 30 Oct 2009, 17:43:04 UTC - in response to Message 943874.

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.


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 ?

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.

Profile Gundolf Jahn
Send message
Joined: 19 Sep 00
Posts: 3184
Credit: 354,976
RAC: 22
Germany
Message 943898 - Posted: 30 Oct 2009, 18:23:33 UTC - in response to Message 943890.

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
Volunteer developer
Volunteer tester
Send message
Joined: 30 Oct 99
Posts: 4137
Credit: 1,004,349
RAC: 238
United States
Message 943915 - Posted: 30 Oct 2009, 19:52:21 UTC - in response to Message 943898.

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)?

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.

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

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

WinterKnight
Volunteer tester
Send message
Joined: 18 May 99
Posts: 8219
Credit: 21,809,192
RAC: 11,864
United Kingdom
Message 943942 - Posted: 30 Oct 2009, 21:52:19 UTC - in response to Message 943898.

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

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
Volunteer tester
Send message
Joined: 5 Jul 99
Posts: 3964
Credit: 31,875,167
RAC: 11,052
United Kingdom
Message 966224 - Posted: 27 Jan 2010, 22:47:14 UTC - in response to Message 934085.

Sorry, I didn't realize that the switch hadn't been implemented. I'll figure out how to do so.

Eric

Now the Astropulse Splitters are online, can we have that Astropulse_v505 switch?, Please.

Claggy

Claggy
Volunteer tester
Send message
Joined: 5 Jul 99
Posts: 3964
Credit: 31,875,167
RAC: 11,052
United Kingdom
Message 974467 - Posted: 27 Feb 2010, 15:11:28 UTC - in response to Message 966224.

Sorry, I didn't realize that the switch hadn't been implemented. I'll figure out how to do so.

Eric

Now the Astropulse Splitters are online, can we have that Astropulse_v505 switch?, Please.

Claggy

Bump,

Claggy

Norwich Gadfly
Avatar
Send message
Joined: 29 Dec 08
Posts: 100
Credit: 488,414
RAC: 0
United Kingdom
Message 974712 - Posted: 28 Feb 2010, 8:45:31 UTC - in response to Message 974467.

Why not just have one Astropulse switch which applies to all Atropulse units being sent out regardless of type ?
____________

WinterKnight
Volunteer tester
Send message
Joined: 18 May 99
Posts: 8219
Credit: 21,809,192
RAC: 11,864
United Kingdom
Message 974745 - Posted: 28 Feb 2010, 11:26:40 UTC - in response to Message 974712.

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
Avatar
Send message
Joined: 29 Dec 08
Posts: 100
Credit: 488,414
RAC: 0
United Kingdom
Message 974801 - Posted: 28 Feb 2010, 17:26:28 UTC - in response to Message 974745.

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.


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
Volunteer tester
Send message
Joined: 4 Jul 99
Posts: 8275
Credit: 44,971,913
RAC: 13,803
United Kingdom
Message 974904 - Posted: 1 Mar 2010, 0:00:02 UTC - in response to Message 974801.

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.

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 ?

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.

Previous · 1 · 2 · 3

Message boards : Technical News : Blip (Sep 16 2009)

Copyright © 2014 University of California