Why did I not get any creds for this unit?
http://setiathome.berkeley.edu/result.php?resultid=1070475636

---

Because you are still using the now-outdated and superceded optimised AP application v4.36, and your wingmate is using the newer v5.00 application issued by Berkeley.

The new updated v5.00 optimised Astropulse application has been available for over a week now - you should upgrade.

P.S. It's faster, too.

Thank you Richard Haselgrove!

---

Why no credits for http://setiathome.berkeley.edu/result.php?resultid=1071895017

I'm using v5.00

---

Why no credits for http://setiathome.berkeley.edu/result.php?resultid=1071895017

I'm using v5.00

Most likely because your first wingmate was running 4.36 so the two results were not strongly similar. It has been re-issued for another host and when that result returns (and that host is also running 5.00, based on other recent results) credit will be issued.

This is another case where the validator bug regarding non-consensus status shows. The true status should be "checked-no consensus" to explain the additional wingman and that the existing results are still waiting for confirmation.

Why no credits for http://setiathome.berkeley.edu/result.php?resultid=1071895017

I'm using v5.00

It's similar to what the previous post had going on with Thomas, except in this case the person using the 4.36 was using the correct stock app at the time they did the task (I have a similar type task I mentioned in Optimised AP v5.00 - initial release). Because their wingman had a compute error on the 27th you were assingned the task. Since the switch to 5.00 was done about a week earlier in the month, your stock app (5.00) was used to process it. Once you returned your result the 4th wingman was sent out because of the conflict. You should recieve credit when the wingamn reports providing they have a valid result. The first wingman that used the stock 4.36 may not.

---

Thank you everyone. Perhaps the BOINC developers will take a look at their list of outcomes/status for a future release. This seems to be a "Validate Error" that doesn't involve a lost WU. There is also an "Aborted by Client" error that isn't in the list and needs to be explained better.

Why no credits for http://setiathome.berkeley.edu/result.php?resultid=1071895017

I'm using v5.00

It's similar to what the previous post had going on with Thomas, except in this case the person using the 4.36 was using the correct stock app at the time they did the task (I have a similar type task I mentioned in Optimised AP v5.00 - initial release). Because their wingman had a compute error on the 27th you were assingned the task. Since the switch to 5.00 was done about a week earlier in the month, your stock app (5.00) was used to process it. Once you returned your result the 4th wingman was sent out because of the conflict. You should recieve credit when the wingamn reports providing they have a valid result. The first wingman that used the stock 4.36 may not.

It has already been posted in the Astropulse Credit? thread that there is a Script running that'll most likely give Credit to any mismatched AP results.

See one of mine, in which even a Client error got credit: wuid=352586706

Note that whatever Credit amount was claimed was given, except for the full on compute error, which was only reported on saturday, and is unlikely to get any when the script is run again.

Claggy

---

Got one as well:

http://setiathome.berkeley.edu/workunit.php?wuid=368868876

---

Ugh you'd think people would read before posting. I guess it's easier to get other people to do your work for you. Always check the astropulse FAQ section. Compare your results against your wingman before posting. Old ap vs. new? Seti will be granting credits to people using the old app if the people running the new app match. you have to wait for the WU to be completed by a 3rd person with the correct app. Notice the enormous waste that is created by not updating your app.

UPDATE UPDATE UPDATE your astropulse app to the 5.0.

It's been mentioned numerous times that it is YOUR responsibility to check for and update your app if you choose to run a 3rd party app. Please make an effort to investigate the problem on your own. search the forums check the
Q&A section.

I guess my point is that we should be reading before writing. Most of the recent posts about AP are repeat preformances because of a failure to search and read previous posts.

We all have problems and most of them are not unique.

---

In a rich man's house there is no place to spit but his face.
Diogenes Of Sinope

Ugh you'd think people would read before posting. I guess it's easier to get other people to do your work for you. Always check the astropulse FAQ section. Compare your results against your wingman before posting. Old ap vs. new? Seti will be granting credits to people using the old app if the people running the new app match. you have to wait for the WU to be completed by a 3rd person with the correct app. Notice the enormous waste that is created by not updating your app.

UPDATE UPDATE UPDATE your astropulse app to the 5.0.

It's been mentioned numerous times that it is YOUR responsibility to check for and update your app if you choose to run a 3rd party app. Please make an effort to investigate the problem on your own. search the forums check the
Q&A section.

I guess my point is that we should be reading before writing. Most of the recent posts about AP are repeat preformances because of a failure to search and read previous posts.

We all have problems and most of them are not unique.

1) The FAQs aren't always very clear, nor the files/examples referred to very well documented leaving the person to guess what is going on f.ex. in the xml file. The Q&A page is for instance still refering to the vers. 4.35, so do you need to change all references to vers. 4.35 to vers. 5.00, or do you add a section for vers. 5.00 and retain the section for vers. 4.35? Or what...?

2) You will be "punished" for upgrading to the latest version in case your wingman hasn't upgraded, and you will be "punished" if you haven't upgraded in case your wingman has upgraded. That sounds like a no-win situation to me.

3) Not all people - including those who run optimized apps - check, check and check again whether there's new program versions available... most people have other tasks to do in their lives besides running SETI. Hence why upgrading may take a little while. And during those days or a week or two it takes for a person to discover and carry out the upgrade, the problems most likely will already be there. And if your wingman on any AP WU takes even longer to upgrade, then you're SOL (see 2).

4) Just dismissing results like that seems highly unreasonable/unfair. Instead the 2 returned results could be set as "pending" awaiting the return of a 3. result. If this 3. result is close to either of the 2 already returned results, then that would be the "final verdict" for all 3 returned results.

Got another 0-credit AP WU today (http://setiathome.berkeley.edu/workunit.php?wuid=369005318). I admit I'm the version 4.36 guy (the other being a 5.00 guy), but both results claimed exactly the same credit.... (so the "close-theory/no-consensus theory" doesn't hold water..) As it is both received a nice, big round zero despite agreeing perfectly. Makes you consider if it's worth continuing to run the AP client at all...

---

Before you decide to abandon Astropulse, know that there is a script run occasionally that will grant credit to differing versions like your situation. As long as you completed the work unit, you will receive credit for it. Patience is the key, as it may take a while - they may even have to manually grant you credit.

And the credit claimed has absolutely no bearing on whether the uploaded result matches. The v5.00 apps do radar blanking, while the v4.xx apps don't - that alone will invalidate results between the two versions.

---

Cruiser
Gateway GT5692 L-f-S Edition
-Phenom X4 9650 CPU
-4GB 667MHz DDR2 RAM
-500GB SATA HD
-Vista x64 SP1
-BOINC 6.2.19 32-bit client
-SSE3 optimized 32-bit apps

1) The FAQs aren't always very clear, nor the files/examples referred to very well documented leaving the person to guess what is going on f.ex. in the xml file. The Q&A page is for instance still refering to the vers. 4.35, so do you need to change all references to vers. 4.35 to vers. 5.00, or do you add a section for vers. 5.00 and retain the section for vers. 4.35? Or what...?

Agreed. I did ask Josh to update it for the (minor) upgrade from v4.35 to v4.36, and it needs it even more for the (major) upgrade from v4.36 to v5.00: unfortunately Josh hasn't posted on the boards since the (Beta) release of v5.00 26 days ago, and I don't know of any way to compel a PhD student an ocean and a continent away to come to the boards and bring things up to date.

2) You will be "punished" for upgrading to the latest version in case your wingman hasn't upgraded, and you will be "punished" if you haven't upgraded in case your wingman has upgraded. That sounds like a no-win situation to me.

If a v4.36 and a v5.00 task fail to generate a definitive answer ('validate'), the task will be sent out afresh to a third computer. In that case, the overwhelming odds are that the new host will be running v5.00. So your best chance of remaining "unpunished" is to be the one who ran v5.00. Not guaranteed, but the best chance.

3) Not all people - including those who run optimized apps - check, check and check again whether there's new program versions available... most people have other tasks to do in their lives besides running SETI. Hence why upgrading may take a little while. And during those days or a week or two it takes for a person to discover and carry out the upgrade, the problems most likely will already be there. And if your wingman on any AP WU takes even longer to upgrade, then you're SOL (see 2).

Again, the second wingman will, most likely, be running v5.00. The chance of your first wingman running v4.36 is higher, because you might be working on a resent task when the original dates from before the change. But any re-issue after you've finished is almost certain to go to a v5.00 host - remember that the stock application is far more common than optimised applications, and all stock crunchers will be on v5.00

4) Just dismissing results like that seems highly unreasonable/unfair. Instead the 2 returned results could be set as "pending" awaiting the return of a 3. result. If this 3. result is close to either of the 2 already returned results, then that would be the "final verdict" for all 3 returned results.

In fact, this is already happening - that's why the tasks are sent out for a third computation. The credit is in fact 'pending', but is (still) being misreported. Another case of the missing PhD student (or his supervisor).

Got another 0-credit AP WU today (http://setiathome.berkeley.edu/workunit.php?wuid=369005318). I admit I'm the version 4.36 guy (the other being a 5.00 guy), but both results claimed exactly the same credit.... (so the "close-theory/no-consensus theory" doesn't hold water..) As it is both received a nice, big round zero despite agreeing perfectly. Makes you consider if it's worth continuing to run the AP client at all...

Although this WU is still technically 'pending', unfortunately your big round zero is likely to be permanent - your new wingman is running the v5.00 stock app, and is likely to agree with your v5.00 wingman, rather than with you.

I have finished two AP WUs. One has been granted credit with an optimized 4.36 app. The wingman has used a stock 4.36. I am waiting for a third wingman to finish in order to have a canonical result. The other WU was finished with valid state, 0 credits. The second wingman used 5.0 and also got 0 credits. We both are waiting for the third wingman. I have suspended all AP crunching until those two WUs get a canonical result. I am using an "untested" Linux optimized AP since the stock AP was too slow on my Opteron 1210 CPU. But it is still crunching MB WUs with AK_V8 optimized app giving good results, always canonical.
Tullio

---

I just want to make sure I understand this correctly.

Although this WU is still technically 'pending', unfortunately your big round zero is likely to be permanent - your new wingman is running the v5.00 stock app, and is likely to agree with your v5.00 wingman, rather than with you.

Does this mean the script being run for others does not include someone in a similar situation and won't include them in the future? Or is it in the process of being worked on?

---

I just want to make sure I understand this correctly.

Although this WU is still technically 'pending', unfortunately your big round zero is likely to be permanent - your new wingman is running the v5.00 stock app, and is likely to agree with your v5.00 wingman, rather than with you.

Does this mean the script being run for others does not include someone in a similar situation and won't include them in the future? Or is it in the process of being worked on?

I discussed this point in a Beta message earlier this year. Quoting (and remember the version numbers in this quote date back to a much earlier epoch):

I think we are seeing the effects of two separate and distinct validation/credit granting processes.

1) Scientific Validation.
Usual rules of strong/weak similarity apply. Credit is granted by the validator process - same amount to everyone, calculated as the [lower of two][middle of three] claims submitted. 4.25/4.26 application pairings fail this test, and would normally go into a 'Checked, but no consensus' pending state.

2) Eric's Benevolence.
Crunchers who achieve a Home Run (qv) with either of 4.25 or 4.26 get the amount of credit they claimed, even if the quorum tips against them when the tiebreaker reports in.

In replying to Karl, I was concentrating on route (1), which I christened "Scientific Validation" above. This sort of validation is the only one which is guaranteed. Because of that guarantee, and because of the science, I would urge (and am trying to persuade) everyone to upgrade to v5.00 asap.

The script - which may or may not be run, regularly or irregularly - implements route (2), "Eric's Benevolence". But it isn't guaranteed, and it does nothing for the science. In particular, it's not likely to be very reliable here, because completed tasks are deleted from the database so quickly. And even Eric, with all the benevolence in the world, can't grant credit to a task which isn't in the database.

And no, my crystal ball doesn't predict how long Eric may go on feeling benevolent.....

I just ran into this with a couple of AP work units myself and I tell you I am pissed about this. I dumped the rest of the AP junk off my laptop, which I was trying this out on and put the original appinfo.xml file back. I had over 83000 secs or cpu time in no no granted credit on a couple of work unit s and that is total BS too!

I might try this again in 6 months to a year but until you people work the frigging bugs out I won't allow any AP work on any of my machines!

If you can't tell by my tone of this post already I am really pissed you let this crap out to the general crunching population!

If you can't tell by my tone of this post already I am really pissed you let this crap out to the general crunching population!

If you choose to use an optimised application, it's up to you to make sure it's uptodate.
If doing that upsets you, then just use the starndard one which will update automatically as they are released.

---

Grant
Darwin NT