Too late to validate?

This happens periodically. Most often after a big outage we see clusters of WU coming out with impossibly short deadlines.

In case they were initially sent out just before the outage to two other users, who processed them during the outage. The server has decided to send them out again, just after the outage, but before the other two users have reported, but with impossibly short deadlines.

I suspect we are going to see lots of these in the next few days :-(
____________
Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

And I don't think they were sent to me with short deadlines; I returned them completed in 2 days (so I don't know what the project deadline for them was).

You can see the deadline in the task details, for example:

Name 12mr10aa.19911.24347.3.10.48_2
Workunit 999039288
Created 1 Jun 2012 | 5:16:22 UTC
Sent 1 Jun 2012 | 8:05:14 UTC
Received 3 Jun 2012 | 17:29:43 UTC
Server state Over
Outcome Success
Client state Done
Exit status 0 (0x0)
Computer ID 6371091
Report deadline 3 Jun 2012 | 17:24:30 UTC
Run time 744.77
CPU time 107.31
Validate state Task was reported too late to validate
Credit 0.00
Application version SETI@home Enhanced
Anonymous platform (NVIDIA GPU)

OK, it's late here, and I'm tired, and these will all probably be deleted by tomorrow morning my time, but there are alot of timing issues about these I don't understand. It's not the credits; it's my not understanding how these came about in the first place. Hopefully, we won't, as Rob suggested, be seeing alot of these.

EDIT: For example, it's curious that the project "deadline" is the same in all 8 workunits, and is almost exactly 5 minutes before I returned the workunits. It's as if when I returned them, S@H said "oops, we don't need these, let's change the deadline and make them invalid".

Yes, it's another side effect of the server mod to only accept 64 at a time. At 17:24:30 UTC your host reported more than 64, so the excess became subject to the resend lost tasks logic. When that found some WUs already had a canonical result it expired them immediately (set the deadline to 'now') rather than resending them. Then on the next attempt to report them at 17:29:43 UTC they were seen as too late.

Joe

You mean basically every user is forced now to set the limit to max 64 tasks per report in his cc_config.xml, otherwise there's risk of loosing credits? Not that I'm going to run into such issues anytime soon, just curious...

However, that still does not explain, why some of the _0 and _1 results for these WUs had so short deadlines.

You mean basically every user is forced now to set the limit to max 64 tasks per report in his cc_config.xml, otherwise there's risk of loosing credits? Not that I'm going to run into such issues anytime soon, just curious...

I think if you set NNT (until all is reported) the server bug will not make false resents to you?

I think if you set NNT (until all is reported) the server bug will not make false resents to you?

Resends are still sent even when NNT is set.

•scheduler: don't resend work if client isn't requesting work

I think if you set NNT (until all is reported) the server bug will not make false resents to you?

Resends are still sent even when NNT is set.

No they aren't, not at this project anyway, at Einstein and other projects with older schedulers, yes resends are sent with NNT set.

Changeset [21823]

•scheduler: don't resend work if client isn't requesting work

Claggy

I think if you set NNT (until all is reported) the server bug will not make false resents to you?

Resends are still sent even when NNT is set.

No they aren't, not at this project anyway, at Einstein and other projects with older schedulers, yes resends are sent with NNT set.

Changeset [21823]

•scheduler: don't resend work if client isn't requesting work

Claggy

Ah OK. I must have seen that with an older client version I was running then. By the date of that change set it looks like 6.10.58 and newer should have that change. I was probably using a 6.10.45 or seomthing when I had that occur.

I think if you set NNT (until all is reported) the server bug will not make false resents to you?

Resends are still sent even when NNT is set.

No they aren't, not at this project anyway, at Einstein and other projects with older schedulers, yes resends are sent with NNT set.

Changeset [21823]

•scheduler: don't resend work if client isn't requesting work

Claggy

Ah OK. I must have seen that with an older client version I was running then. By the date of that change set it looks like 6.10.58 and newer should have that change. I was probably using a 6.10.45 or seomthing when I had that occur.

That's the scheduler on the server, ie on synergy, not the scheduler in the client,
older version of Boinc (pre 6.10.x) used to still ask for work even if the preferences were set to not use a resourse, (it was a server side preference then)
Boinc 6.10.x and later used different preferences (i think they were combined on the website later) that stops Boinc 6.10.x and later from even asking for work,

Claggy