Hi guys,

I just gut no credits for 18 WUs because of "No Reply", ie "too late".
But these units were returned only 4 days after they had been sent. All these units were sent on April 4th 2:42 UTC and reported on April 8th 10:52 UTC.
This is one example of such a work unit:
122521997

This has to be an error. At least I hope it to be an error, I'd hate to lose the credits for 18 WUs.

Has someone else had the same problem?
Is there a way to get the credits?

---

Hi guys,

I just gut no credits for 18 WUs because of "No Reply", ie "too late".
But these units were returned only 4 days after they had been sent. All these units were sent on April 4th 2:42 UTC and reported on April 8th 10:52 UTC.
This is one example of such a work unit:
122521997

This has to be an error. At least I hope it to be an error, I'd hate to lose the credits for 18 WUs.

Has someone else had the same problem?
Is there a way to get the credits?

You may still get credit for ones that have not reached Quorum like:
http://setiathome.berkeley.edu/workunit.php?wuid=122522026 and http://setiathome.berkeley.edu/workunit.php?wuid=122522012. But I think any that are 4th results will not get credit.

---

Sir Arthur C Clarke 1917-2008

Seti Enhanced has been out since May 6th of 2006. Before that the deadlines were a fixed 14 days, but now with the "enhanced" version, they change the deadlines pursuant to the Angle Range of the WU. Deadlines vary between 4 and 55 days. See this post in the "enhanced FAQ" sticky thread.

Hi guys,

I just gut no credits for 18 WUs because of "No Reply", ie "too late".
But these units were returned only 4 days after they had been sent. All these units were sent on April 4th 2:42 UTC and reported on April 8th 10:52 UTC.
This is one example of such a work unit:
122521997

This has to be an error. At least I hope it to be an error, I'd hate to lose the credits for 18 WUs.

Has someone else had the same problem?
Is there a way to get the credits?

In all probability these are "ghost units", i.e., results that appear on seti@home servers but are actually missing from your pc.....

These were never reported back, the time you have mentioned as being reported back is actually the deadline for the workunit.

Unless of course, you had downloaded and crunched these units but then detached and reattached to seti without reporting the finished workunits first.

---

In all probability these are "ghost units", i.e., results that appear on seti@home servers but are actually missing from your pc.....

These were never reported back, the time you have mentioned as being reported back is actually the deadline for the workunit.

Unless of course, you had downloaded and crunched these units but then detached and reattached to seti without reporting the finished workunits first.

bounty.hunter,
you are right of course, the WUs have not been reported. However I did not
detach/reattach the project either. I have no access to my machines right now, so I can't tell if these are "ghosts".

astro,
In my opinion, 4 days is an awfully short time to return a result, I use a 3 day cache.

---

Hi cormacolindo,

In my opinion, 4 days is an awfully short time to return a result, I use a 3 day cache.

Your Boinc client takes care that these workunits are reported in time ("Using earliest-deadline-first scheduling because computer is overcommitted" etc.).

But your computer has already crunched much younger workunits with much longer deadlines. Indeed, this is a big evidence that these missing workunits are ghosts, .

Regards,
Carsten

You may still get credit for ones that have not reached Quorum like:
http://setiathome.berkeley.edu/workunit.php?wuid=122522026 and http://setiathome.berkeley.edu/workunit.php?wuid=122522012. But I think any that are 4th results will not get credit.

If a work unit is returned before the deadline, it will get credit -- even if it is the 4th result, and even if the other work units are returned well before the last one.

If the first three do not form a quorum, BOINC will assign new results with a later deadline -- if you get your work in before the new deadline, your late work unit will still get credit.

---

Hi cormacolindo,

In my opinion, 4 days is an awfully short time to return a result, I use a 3 day cache.

Your Boinc client takes care that these workunits are reported in time ("Using earliest-deadline-first scheduling because computer is overcommitted" etc.).

But your computer has already crunched much younger workunits with much longer deadlines. Indeed, this is a big evidence that these missing workunits are ghosts, .

Regards,
Carsten

Also, be aware that work units (WU)'s with only a 4 day deadline will move ahead of units with later deadlines! Look in your "messages" tab and you'll see, (in addition to the message mentioned!) right after the WU downloads, that "the computer is overcommitted"; and that "work fetch is suspended".

I agree that 4 days is too short a deadline for these very large angular range (AR) WU's... I think 6-7 days is more like it. (-or whatever doesn't trigger the "overcommited" status!) I keep a 4.5 day cache (for a quite fast computer, thank you!) so I can keep crunching when Berkeley has problems, and these mess up my chances for getting Canonicle results. (the result that is kept by SETI after verification.) I've been known to increase the cache to 9 days when I'm away from home for a few days!

If you're gonna be away from home, check for abnormally short "to completion" times in the "tasks" tab - and upload those just b4 you leave! (I'd set the cache to 9 days the day before I leave, and do this final upload [with "no new work" turned on] just before departure... make sure after the WU's are all uploaded that you hit the "update" button to report them!) Of course, ya gotta remember to re-set it back to your usual cache after ya get back...

---

.

Hello, from Albany, CA!...

hello i posted this question on another thread but i think it belongs here. so here we go i am using chickens 2.2b with graphics and every thing was running fine i thought until last night when my results tarted being marked overdo when they were not the last one was sent last 4/12/2007 and was not do until 4/26/2007 what is going on hear? help please

thanks

---

I'm not sure I understand your problem here. The only "problem" results I see in your host listing are a few user aborted downloads, and a batch where BOINC detached from SAH for some reason. None have gone "red" at this point which is the online indication of an overdue result.

As far as the aborted DL's, perhaps you're intrepreting the reported date as the deadline. For this column "In Progress" is green and displays the deadline, "In Progress, but late" is red and displays the deadline, "Completed" is black and displays the date and time you reported the result.

The detached client results are a different matter. Is not all that common but BOINC can end up losing it's host ID have new one spawned from the project, but in this case it looks like you did the detach from BOINC Manager. Keep in mind that these results will go "red" eventually, since a part of the detach process is a project reset and therefore the result input files were dumped. Also, any which were completed but not reported yet were dumped as well.

HTH,

Alinator

There are a few in his/her result list - like 512527448 (from about 15 pages in :-( ) - which match the thread description.

Sent 5 Apr 2007 10:09:24 UTC 
Received 13 Apr 2007 12:32:15 UTC 
Outcome Success 
Report deadline 30 Apr 2007 3:50:58 UTC 
Validate state Result was reported too late to validate 
Claimed credit 62.1284673103579 
Granted credit 0 

Definitely something wrong there, but I don't know if it's possibly related to the detach/attach.

OOPS, missed that sorry! :-(

That is strange! Maybe this is related to the "Zombie Hunt" Matt's been running this week. He made a post over in Tech News there was a problem and it didn't quite work out as he intended. This isn't the same effect he was talking about but I suppose the errant "dumping" of some WU data could result in this.

Alinator

I'm not sure I understand your problem here. The only "problem" results I see in your host listing are a few user aborted downloads, and a batch where BOINC detached from SAH for some reason. None have gone "red" at this point which is the online indication of an overdue result.

As far as the aborted DL's, perhaps you're intrepreting the reported date as the deadline. For this column "In Progress" is green and displays the deadline, "In Progress, but late" is red and displays the deadline, "Completed" is black and displays the date and time you reported the result.

The detached client results are a different matter. Is not all that common but BOINC can end up losing it's host ID have new one spawned from the project, but in this case it looks like you did the detach from BOINC Manager. Keep in mind that these results will go "red" eventually, since a part of the detach process is a project reset and therefore the result input files were dumped. Also, any which were completed but not reported yet were dumped as well.

HTH,

the reason for the aborted downloads is because they would not download the system kept trying to download them but would stop after only downloading .9k of them over and over again if you know what caused that please tell me so i don't have to detach any more and if i can reattach them

thanks
Alinator

---

OK, the download problem was most likely a result of the "Zombie Hunt" trouble Matt was talking about. You should be able to re-attach now without issues.

Generally speaking the worst thing you can do if you're running the recommended version is to just start resetting the project and/or detaching hosts when BOINC falls of out of it's normanl pattern, especially right now as the SAH team is refining their backend and preparing to rollout some new stuff.

There was a time not that long ago where this was about the only viable alternative, but that day is past for the most part. For example I have a host which pick up two days of stalled DL's during this event. I didn't touch it and the problem cleared on it's own, without a single lost completed result or a "ghost" DL AFAICT.

That's not to say new bugs don't crop up every so often, but again immediately going to a reset or detach may eliminate important information which could help get to the root issue which caused the problem in the first place. In that event it may appear you "solved" the issue, but it could come back to bite you again and you'd be no further along in getting to the real solution than you were the first time. It's almost always better to try and work the problem first. If you need help doing that, that's why a lot of us are here and are more than willing to work with you on resolving the immediate problem and determining the root cause so it can be eliminated in a future build of BOINC and/or the science app.

Alinator

is boinc having problems iam in class 07 07 2000... when i go to user results it has not changed in 4days and goes for everyone else in that group .. i can upload and d/l fine and it slows my progress in other other areas , but not in my class standing

I'm assuming you're talking about the numbers on the third party stat sites, and the reason for that is they haven't made a xml export stat run here since 4/09.

Don't worry, when they do you will most likely see a big jump in your numbers after that. ;-)

Alinator

thank you for your info...at times i wish we still had classic LOL

There are a few in his/her result list - like 512527448 (from about 15 pages in :-( ) - which match the thread description.

Sent 5 Apr 2007 10:09:24 UTC 
Received 13 Apr 2007 12:32:15 UTC 
Outcome Success 
Report deadline 30 Apr 2007 3:50:58 UTC 
Validate state Result was reported too late to validate 
Claimed credit 62.1284673103579 
Granted credit 0 

Definitely something wrong there, but I don't know if it's possibly related to the detach/attach.

I got many of these errors today Look at 517071948, for example: sent apr 12 , result received apr 14, deadline apr 25, and "too late to validate"...
In fact, almost all the results uploaded today Apr 14 have that error.
But: this is only for one linux box (2*Intel 5160), all my others computers got credits today.

Then, why ? Its not sure they have an ET clock in Berkeley, because most computers have credits. May be its the optimized seti client. But i have optimized clients on all the computers, and they should more likely give "invalid", not "too late". Also, the computer date is OK (Apr 14, UT+1)

---

I got many of these errors today Look at 517071948, for example: sent apr 12 , result received apr 14, deadline apr 25, and "too late to validate"...
In fact, almost all the results uploaded today Apr 14 have that error.
But: this is only for one linux box (2*Intel 5160), all my others computers got credits today.

Then, why ? Its not sure they have an ET clock in Berkeley, because most computers have credits. May be its the optimized seti client. But i have optimized clients on all the computers, and they should more likely give "invalid", not "too late". Also, the computer date is OK (Apr 14, UT+1)



[/quote]

Sorry, a copy glitch. The example was:
http://setiathome.berkeley.edu/result.php?resultid=515699866

---

I got many of these errors today Look at 517071948, for example: sent apr 12 , result received apr 14, deadline apr 25, and "too late to validate"...
In fact, almost all the results uploaded today Apr 14 have that error.
But: this is only for one linux box (2*Intel 5160), all my others computers got credits today.

Then, why ? Its not sure they have an ET clock in Berkeley, because most computers have credits. May be its the optimized seti client. But i have optimized clients on all the computers, and they should more likely give "invalid", not "too late". Also, the computer date is OK (Apr 14, UT+1)


Sorry, a copy glitch. The example was:
http://setiathome.berkeley.edu/result.php?resultid=515699866

No, you were right the first time - result 517071948 is the example.

This machine is one of the ones which has suffered 'client detached' - I think this is far more likely to be the cause of the 'too late to validate' error, rather than optimisation or a faulty RTC.

Maybe the error message should be read as (or amended to read) 'Result reported after client detached'.