My Linux box has been working on an Astropulse binary for 7.5 days (629,645 seconds to be exact).

Task ID 1082351622, work unit ID 361753301

Credit claimed 756.27. Credit given 0. No reason given... No error

Thank you very much SETI and goodbye. I'll find another project.

My Linux box has been working on an Astropulse binary for 7.5 days (629,645 seconds to be exact).

Task ID 1082351622, work unit ID 361753301

Credit claimed 756.27. Credit given 0. No reason given... No error

Thank you very much SETI and goodbye. I'll find another project.

Looking at it, your got zero credit because your wingman was using the outdated version of the Astropulse client (4.36). This happens to all of us, and what happens is the task goes out to a third person to compare the results of the two that have been turned in.

Because of the v4 to v5 switchover, there are some issues with people losing credit. Some get it, some don't. Once the changeover is complete (and once people using old v4 apps quit crunching Astropulse, or get the v5 application), credit-granting should go back to normal.

That's what we are stuck on right now is getting people to quit using v4. I'm waiting on an optimized v5 app for Linux, so until then, I'm not crunching AP on those two boxes. That's what other people need to be doing, as well.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

Good luck on other projects.

if your going crunch because of some number.. best that you go now

---

My City

Not even so much as a "Why?" but a "Goodbye". Certainly not a reasonable way to be, but I wouldn't dare to tell people how they should be. Only that if you had done a search, you would have seen this discussed ad nauseum all over the place, with appropriate explanations given in each thread. But a person with little patience and little reasoning doesn't allow enough time for searching and explanations.

Bye.

---

My Linux box has been working on an Astropulse binary for 7.5 days (629,645 seconds to be exact).

Task ID 1082351622, work unit ID 361753301

Credit claimed 756.27. Credit given 0. No reason given... No error

Thank you very much SETI and goodbye. I'll find another project.

A lot of new crunchers have expressed some frustration over this issue, but in time you do usually get your credits.

Good luck on other projects.

if your going crunch because of some number.. best that you go now

Some crunchers express this but I think that since we see a lot of posts expressing questions on the issue, maybe it should be looked at if they want AP to be accepted.

I also have AP turned off till the issue is resolved.

---

Not even so much as a "Why?" but a "Goodbye". Certainly not a reasonable way to be, but I wouldn't dare to tell people how they should be. Only that if you had done a search, you would have seen this discussed ad nauseum all over the place, with appropriate explanations given in each thread. But a person with little patience and little reasoning doesn't allow enough time for searching and explanations.

Bye.

True enough.

OTOH, this isn't Beta. Having the validator giving the impression the tasks are junk rather than CBNC and needing to go to another replication is fairly unsat.

It's not like this problem just popped up today and should be on the fast track to getting fixed, if not for the simple reason that MB at least gives the correct info about the WU state and AP doesn't. That's just asking for confusion. ;-)

Alinator

I had been using an untested Linux optimized app based on 4.36 which took 56 hours on my Opteron box. Two WUs crunched with it are still awaiting a third and fifth wingman to terminate. Then I loaded a 5.0 app that I mistook for an optimized app, but it isn't. It is awfully slow on my AMD chip.
Tullio

---

On my newest (and fastest) machine I have 6 AP units that have been given zero credit; all WU's took about 170 hours to complete, and the oldest was done in October. This is not a small problem. All of my other machines have 0 credit AP units. Multiply that by the thousands of participants who, like me, did not know they could "turn off" AP, and there must be a lot of collective frustration.

if your going crunch because of some number.. best that you go now

Some crunchers express this but I think that since we see a lot of posts expressing questions on the issue, maybe it should be looked at if they want AP to be accepted.

I also have AP turned off till the issue is resolved.

The reason some people say "if you are that worried about some number, best go now" is that many of those here take this way too seriously.

Sure, we're fascinated by the idea behind SETI, we want to do well, but there are enough safeguards that the chance of bad work polluting the database is very low.

We also have to keep in mind that Astropulse takes 20 to 30 times longer to crunch, and has much longer deadlines. If work doesn't validate, it will take 20 to 30 times longer for the third result to be assigned and crunched.

I'm only crunching Astropulse -- I only do Multibeam if AP isn't available.

If your system never gets credit, you need to figure out what is wrong with it, but the occasional missed (or long-delayed) credit is just part of the game, and happens to everyone.

---

Hello Pete, isn't it just credit? Why does it matter so much, it's just a few numbers that you get for completing a task. It happened to me and I didn't drop everything and leave. Pick yourself up and try again. I hate to be so harsh, but it's the truth. And hey, I have no sympathy for you, your decision.

Goodluck on other projects.

---

- Luke.

I'm only crunching Astropulse -- I only do Multibeam if AP isn't available.

If your system never gets credit, you need to figure out what is wrong with it, but the occasional missed (or long-delayed) credit is just part of the game, and happens to everyone.

Yes, I do agree with you Ned. I do not care so much about credits as I care about how the project is being looked after.

We are getting a lot of posts from people about 0 credit for AP work units. It should be looked at by the project administration.

---

I'm only crunching Astropulse -- I only do Multibeam if AP isn't available.

If your system never gets credit, you need to figure out what is wrong with it, but the occasional missed (or long-delayed) credit is just part of the game, and happens to everyone.

Yes, I do agree with you Ned. I do not care so much about credits as I care about how the project is being looked after.

We are getting a lot of posts from people about 0 credit for AP work units. It should be looked at by the project administration.

I don't believe it falls under SETI@home project administration, the optimized apps are created by the team at lunatics.net.

The problem is more like two different optimized apps crashing into one and another (in this case; 4.36/4.35 & 5.00) when Wingmen are paired up, if they have different executables/applications, it gets falsely tagged as "completed successfully" and no credit in some circumstances is granted (there are alot of variables here). When installing these optimized executables, it says use at your own risk, that includes the risk of receiving no credit for a result.

That's why I don't feel people can moan and whinge on about not receiving credit when they knowingly installed a optimized executable that had disclaimers and warnings written all over it.

---

- Luke.

I'm only crunching Astropulse -- I only do Multibeam if AP isn't available.

If your system never gets credit, you need to figure out what is wrong with it, but the occasional missed (or long-delayed) credit is just part of the game, and happens to everyone.

Yes, I do agree with you Ned. I do not care so much about credits as I care about how the project is being looked after.

We are getting a lot of posts from people about 0 credit for AP work units. It should be looked at by the project administration.

Every one I've seen with zero credit has been reissued.

That means it has been sent to a third "cruncher" to be re-crunched.

There is a known issue that 4.x clients don't validate against 5.x clients, and we know that the anonymous platform allows optimized clients to mix versions.

Because relatively few people actually read the forums, we have a higher percentage of optimized applications, a higher percentage of the "very interested" and a higher percentage of people who would notice.

All of the "zero credit" issues I've seen involve an optimized app. and the stock application. I'm sure the folks behind the opti. apps are on top of this, and I'll defer to them on the fixes.

... and I think, unfortunately, there are people who install optimized crunchers and do not realize that they are responsible for staying up to date: if you aren't going to stay on top of the updates, you should let BOINC manage client software and run the standard apps.

---

That's why I don't feel people can moan and whinge on about not receiving credit when they knowingly installed a optimized executable that had disclaimers and warnings written all over it.

More to the point: if they've lost some credit, they've also gained by running the faster applications.

---

I don't believe it falls under SETI@home project administration, the optimized apps are created by the team at lunatics.net.

The problem is more like two different optimized apps crashing into one and another (in this case; 4.36/4.35 & 5.00) when Wingmen are paired up, if they have different executables/applications, it gets falsely tagged as "completed successfully" and no credit in some circumstances is granted (there are alot of variables here). When installing these optimized executables, it says use at your own risk, that includes the risk of receiving no credit for a result.

No,the problem here's that the admins screwed up. Since AP 5.00 introduced the radar blanking, it's a totally different app compared to AP 4.3(x).

Therefor it should have gotten a new name tag like AP enhanced or something similar... That would have avoided that miss pairing between different AP versions.

---

Join BOINC United now!

We are getting a lot of posts from people about 0 credit for AP work units. It should be looked at by the project administration.

The thing is, even if the project administration isn't speaking up on the boards, they are definitely looking into it from their end. In essence, one shouldn't judge the lack of posting by the Admins as ignoring the situation, but instead the fact that it takes time to fix problems and when those problems do get fixed, it was because the Admins were working on it behind the scenes.

We are getting a lot of posts from people about 0 credit for AP work units. It should be looked at by the project administration.

...
All of the "zero credit" issues I've seen involve an optimized app. and the stock application.

Ned,

You're not looking hard enough. Take, for instance, workunit 361753301, which featured in the opening post of this very thread:

1051074938 4596670 9 Nov 2008 10:02:57 UTC 9 Dec 2008 10:02:57 UTC Over No reply New 0.00 --- ---
1051074939 3435128 9 Nov 2008 10:02:57 UTC 22 Nov 2008 11:38:49 UTC Over Success Done 154,308.20 760.66 0.00
1082351622 4011464 9 Dec 2008 10:03:13 UTC 18 Dec 2008 1:15:19 UTC Over Success Done 629,645.50 756.27 0.00
1092116643 3894759 18 Dec 2008 1:15:33 UTC 17 Jan 2009 1:15:33 UTC In progress --- New --- --- ---

Task 1051074939 (zero credit) was crunched by the stock app, and task 1082351622 (zero credit) was crunched by - the stock app.

OK, admittedly by different revisions of the stock app, and the zero credit isn't really zero yet, just pending: but in this very case both the version problem and the validator problem are directly attributable to the project - not an optimiser in sight. And look what the impact on the OP was - that's another crunching volunteer lost to the project for good unless the forum can talk him down from the edge.

OzzFan, I hope you can supply a substantiated and accredited reference for your statement that the project "... are definitely looking into it from their end.". I haven't seen any sign of it, and I read the forums pretty assiduously.

My understanding remains: the v4.3x/v5.00 validation issue is self-limiting, and will quickly fade into insignificance as any remaining v4 tasks time out and are re-issued to v5 hosts. In fact, a significant milestone was passed on that route yesterday, when the very last tasks issued as stock v4.36 before the v5.00 release passed their deadline dates.

The mis-statement of task status (the loss of 'pending' and 'Checked, but no consensus'), on the other hand, is another matter. It requires pro-active action by admins: they are aware of the problem: and the fix is utterly trivial (Eric collected the code revision - affecting all of four lines - from Joe Segur at the Lunatics board on 14 November). Yet now the same misleading information is starting to appear as a result of the MB validator's work - there are two bugs, where there was one (easily fixable) one before. Why?

OzzFan, I hope you can supply a substantiated and accredited reference for your statement that the project "... are definitely looking into it from their end.". I haven't seen any sign of it, and I read the forums pretty assiduously.

If there were an accredited reference for me to proffer, then that would negate the first part where I said "even though they are not posting". So no, I cannot offer any references, only what I've seen elsewhere.

We are getting a lot of posts from people about 0 credit for AP work units. It should be looked at by the project administration.

The thing is, even if the project administration isn't speaking up on the boards, they are definitely looking into it from their end. In essence, one shouldn't judge the lack of posting by the Admins as ignoring the situation, but instead the fact that it takes time to fix problems and when those problems do get fixed, it was because the Admins were working on it behind the scenes.

Ozzfan is completely right here. Matt has actually indicated in some other threads that they are indeed aware there are some bugs in the CUDA application and that the team is working on stomping them as fast as they can.

Some of the ones i have seen the CUDA computation suddenly starts affecting my active display on my GeForce which immediately follows by any queued workunits to finish in roughly 25 seconds and claim something silly like .02 credit :)

Im thinking that these are either super-shorties (possible but unlikely that ALL of these are) or something in the CUDA driver didnt handle a computation correctly and resulted in compute errors accross each of these WUs which the software for some reason still saw as completed units.

Another bug to be aware of, my SETI app requested two AP units for my CPU to chomp on. And then didnt get any more CUDA processeable workunits because it did not realize that even though i had 60k seconds of work already, they were all CPU WU and it had an unutilized resource.

There are always some bumps when you make architectural changes to an application. With patience they will be worked out.

---

-W
"Any sufficiently developed bug is indistinguishable from a feature."

OzzFan, I hope you can supply a substantiated and accredited reference for your statement that the project "... are definitely looking into it from their end.". I haven't seen any sign of it, and I read the forums pretty assiduously.

http://setiathome.berkeley.edu/forum_thread.php?id=50767&nowrap=true#841695

My understanding remains: the v4.3x/v5.00 validation issue is self-limiting, and will quickly fade into insignificance as any remaining v4 tasks time out and are re-issued to v5 hosts. In fact, a significant milestone was passed on that route yesterday, when the very last tasks issued as stock v4.36 before the v5.00 release passed their deadline dates.

The mis-statement of task status (the loss of 'pending' and 'Checked, but no consensus'), on the other hand, is another matter. It requires pro-active action by admins: they are aware of the problem: and the fix is utterly trivial (Eric collected the code revision - affecting all of four lines - from Joe Segur at the Lunatics board on 14 November). Yet now the same misleading information is starting to appear as a result of the MB validator's work - there are two bugs, where there was one (easily fixable) one before. Why?

Definitely an issue :)

Wouldn't be the first time that a bug re-surfaced in an application based on differences in fixed versions and multiple developers. Annoying but fixable.

---

-W
"Any sufficiently developed bug is indistinguishable from a feature."