I've got about ten of these until now:
"Created: 4 Mar 2008 11:59:57 UTC
Sent: 5 Mar 2008 6:14:34 UTC
Received: 9 Mar 2008 21:19:55 UTC
Report deadline: 28 Apr 2008 17:58:13 UTC

Validate state: Task was reported too late to validate"
Too late...when there are about six weeks left ???

A known problem...or something new ?

The other thing that is strange about these kind of WUs: it ran 2,994.64 secs...and should receive 86.91 credits. I've never ever had such an high credit-per-secs-value before...

I do wish people who cache 9269 tasks across 12 hosts would post a direct link when one of them turns out to be interesting.

I do wish people who cache 9269 tasks across 12 hosts would post a direct link when one of them turns out to be interesting.

lol :-)

---

63. (1) (b) "music" includes sounds wholly or predominantly characterised by the emission of a succession of repetitive beats

Ive noticed this once myself. My wingman reported his and got credit for it without a third result sent out

---

@Richard: Good point. Example 1 and example 2: all WUs with granted credit=0...

---

Hmmm...

Something in the backend had to have messed up.

1.) None of the tasks was anywhere near the deadline for any of the hosts.

2.) These WU's should never have even gone to a third task issued in the first place, AFAICT.

3.) Even if there was some legitimate reason to send more tasks, there's no way a follow up (or original for that matter) task should be declared to late to validate before its deadline expires.

Bottom line here; It looks like the project broke just about every scoring rule in the book! ;-)

How rude! :-)

Alinator

Well, I was actually thinking of a link to the WU in question, but never mind ;-)

Both Example 1 and example 2 point to host 4191504. That host has a number of tasks marked 'client detached', yet it has retained a task list of 1106 tasks and a creation date of 2 February 2008.

Suggestion: the server records 'client detached', and issues a third copy of the WU to another host to replace the "lost" result. Then some time later the original host (which either didn't detach, or re-attached under the same ID) reports the result after all. Would that count as "Task was reported too late to validate" ?

Now all we have to do is to track down the 'detach' event and its cause.

Well, I tried for over a week to let run Tiger instead of Leopard as OS on that rig (this tests included exchanging the boinc data folders between the different partitions) and during that time once something must have screwed up because after that all tasks that hadn't been returned yet showed up as 'client detached'. Haven't thought about that as a reason because the results reported after that 'crash' did all validate...until today. But it makes sense. Thanks for the suggestion...

---

....the results reported after that 'crash' did all validate...until today.

Probably the initial results reported in before the replacement wingmates got round to reporting would form part of the quorum and get considered for validation.

But once the replacement wingmates started reporting in, your results would be classed as a trailer and discounted.

Just have to hope that some of the 'detached' tasks were issued to wingmates with caches as large as yours - then you might still be the second (or first) result back.

I've got about ten of these until now:
"Created: 4 Mar 2008 11:59:57 UTC
Sent: 5 Mar 2008 6:14:34 UTC
Received: 9 Mar 2008 21:19:55 UTC
Report deadline: 28 Apr 2008 17:58:13 UTC

Validate state: Task was reported too late to validate"
Too late...when there are about six weeks left ???

A known problem...or something new ?

The other thing that is strange about these kind of WUs: it ran 2,994.64 secs...and should receive 86.91 credits. I've never ever had such an high credit-per-secs-value before...

I have several now I am worried will be too late. Mine are done, with deadline of 03-08 and a few 03-09. I finished a few days ago, and I am still waiting. . It still seems the credit backlog is there for me.

---

Suggestion: the server records 'client detached', and issues a third copy of the WU to another host to replace the "lost" result. Then some time later the original host (which either didn't detach, or re-attached under the same ID) reports the result after all. Would that count as "Task was reported too late to validate" ?

Now all we have to do is to track down the 'detach' event and its cause.

That's happened to me. I had a BOINC directory copied and run from a different location (playing around with 64-bit version). It downloaded some WU, but I detached from the other copy.

The exception to this guys problem was that my machine crunched all the tasks and returned them within 24 hours. I got the usual credit for them all without any ill effects.

I would image that if I did not return those tasks quickly enough, the same error would appear.

Suggestion: the server records 'client detached', and issues a third copy of the WU to another host to replace the "lost" result. Then some time later the original host (which either didn't detach, or re-attached under the same ID) reports the result after all. Would that count as "Task was reported too late to validate" ?

Now all we have to do is to track down the 'detach' event and its cause.

I've similar issue (project generated detatch events) on a host that runs BoincPE with persistence. I've had a few power outages recently that causes some WU's to crunch and report twice (WUs that have already reported before the power drop are recrunched when power and the network backup, still containing the uncrunched WUs, is restored to the host). Seems that the project doesn't like this and will sometimes detatch (and reattach?) the host without making the WU's redundant. I know that I've never pressed the detatched button, rather the project seems to do it. Maybe we could call these zombies since they seem risen from the dead.

A different issue presents when a host is issued WU's and drops power before the next backup...Those WUs become ghosts (I think), the recently sent WU's show up on the project task list for that host, but the host doesn't have the WU's or any record of them, they are not detatched, and wingmen are left hanging til expiration. This wasn't a problem back when we had resends:-(

What I can do for these ghosts, if I notice, is drain the cache, then detatch/reattatch. This should cause new results to be generated and sent out before deadline.

Is there such thing as being redundant before having quorum?

---

I have just been checking some WU's and noticed a difference in report deadlines between bonic and seti of one hour. Host are running GMT. Have I got a setting wrong somewhere.

---

I have just been checking some WU's and noticed a difference in report deadlines between bonic and seti of one hour. Host are running GMT. Have I got a setting wrong somewhere.

Do the tasks have deadlines after 30 March 2008 01:00 UTC? British and European clocks change to Summer Time (DST).

---

Sir Arthur C Clarke 1917-2008

And here in the US (Where one would find the Berkeley servers) we changed to DST about 30 hours ago.

---