Why no credit for this one, it have two completed WUs with both status "Valid", still no credit granted for any of them !???


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

It's a long 23 h AstroPulse WU and should have generated over 700 in credits that seems to be lost *sobs* ...

---

No need to worry if there is another replication of the task showing for the WU.

The old problem of not correctly representing the Checked But No Consensus validation state was reintroduced recently, both in AP and MB.

Odds are you will get credit when the new wingman reports.

<edit> Ohhh... I see you were talking about an AP task, so there is a better chance you'll get a Zed than for MB, but the odds are still in your favor.

Alinator

Hi Crystallize,
Not sure which computer is yours but I'd guess this has a lot to do with it..
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 896
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 1024
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 1152
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 1280
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 1408
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 1536
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 1664
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 1792
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 1920
In ap_

Whoever this is it goes on and on so the two results were probably not similiar enough.

---

PROUD MEMBER OF Team Starfire World BOINC

No it was not that one anyways, mine was the one that got reported today the 11th ... the other one.

Well I really hope I wont loose that credit, it would be so much that would go lost !

---

I had a AP WU like that. As soon as the third cruncher reports another result that matches the other 2, all of you will get credit.

---

Both PCs anonymous. That really, really helps the analysis - not.

The dual Xeon Enterprise Server x64 is running the stock v5.00 Astropulse application (the one with the endless mainloop). They will almost certainly get credit eventually, when the tie-breaker reports in.

The Core2 6400 Windows 2000 is running the obsolete optimised v4.35 Astropulse application - the one which should have been upgraded on or soon after 21 November 2008. They will likely not get credit.

Crystallize mentions 23h, or 82,800 seconds - which doesn't match either of them. So I don't know whether she needs to upgrade or not.

... mine was the one that got reported today the 11th ...

So you were the one with the obsolete app.

You should re-visit New Optimized Apps Links and upgrade asap.

No it was not that one anyways, mine was the one that got reported today the 11th ... the other one.

Well I really hope I wont loose that credit, it would be so much that would go lost !

Then you are the one running the optimised 4.36!, you should really upgrade immediately to the current release, which is v5.00, see Optimized Astropulse 5.00 for Windows Updated 11.21.08 w/ newer version This is a REQUIRED UPGRADE if you are currently running optimized version 4.35

Claggy

Edit: Beaten again

Edit: Beaten again

But at least we validated - strongly similar! :-)

Edit: Beaten again

But at least we validated - strongly similar! :-)

Yeah, no third wingman needed for that consensus. :p

---

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