I vaguely remember a good answer to this question, but I cannot put my finger on it...
I have a tasks on my laptop that are (just like everybody else), waiting to upload. Some of theme are now overdue.

Do they still validate and I (eventually) receive credit or do they time out and get sent to another computer to crunch?

And yes, we are all annoyed right now with the current uploading issues, but there is no need to bite peoples heads off. It looks childish IMO.

---

- Luke.

Depends.
If they get back before the re-send gets back, you should get credit.
If they don't, there's a good chance you won't. But there's also the possibility of intervention by the project that could in some way allow credit.

-Dave

---

I'm doing this without consulting notes, so corrections are welcome.

The validators are responsible for checking deadlines and reissuing work.

If the validators don't look at your work unit (perhaps because they're busy processing freshly-reported work) then the deadline on that work unit will not be checked.

I've also seen that the due-date checks can be disabled. I'm guessing that they'll do that this time.

Also, if you get your result back before the reissue is crunched and credited, you will still get credit.

You will not be shut out for missing an arbitrary date.

---

A lot of us already have blocks of task time-outs this week.... and it's only gonna get bigger each hour that goes by ;-)

Would be nice in the future if they could hit PAUSE on the shotclock when the project has such customer woes.

[Edit] Here is one from Luke, unless this was a Ghost --> http://setiathome.berkeley.edu/results.php?hostid=5243400&offset=0&show_names=0&state=5

I vaguely remember a good answer to this question, but I cannot put my finger on it...
I have a tasks on my laptop that are (just like everybody else), waiting to upload. Some of theme are now overdue.

Do they still validate and I (eventually) receive credit or do they time out and get sent to another computer to crunch?

Assuming everything is running on automatic (no deadline extensions, inhibition of work creation or the like), I think the sequence is:

As the clock ticks past deadline, a new task is created in the database, so there are three copies for that WU - four, if your wingmate has also struggled with uploads.

That new copy/copies goes to the back of the queue for sending out. That's a long, slow-moving line at the moment - it'll be a long time before the new work gets sent out, and even then it has to be crunched, and then join the line to get back in again.

During that time, all four copies are in play. Any two of them could come back, validate, and be granted credit.

The best outcome is for the original two to upload and report before the replacements have even left the building. Then they are cancelled - "Didn't need" - and they don't waste bandwidth or anybody's time crunching them.

Considering that there is only ~56k tasks ready to send and returning rate ~14k results (~7 k tasks in usual replication of 2 conditions) and assuming stationary flow of work there is only few hours while whole work queue will be rotated.
Not too much place to gracefully cope with already deadlined tasks.
Most probably worser scenario will be implemented.
Newly created tasks will be send to 2 new crunchers, and will be started before older 2 will get back to validator.
Then they will not stop even if first 2 pass validation OK. Most probably all 4 will recive their credits, here nothing to fear from credit-liker point of view, but effective effort to process this task will be doubled and project performance will take hit.

Glass half full or glass half empty? Yes, yours is a likely outcome too: but if you had done the calculation at 17:00 yesterday, with ~140K ready to send and ~5K returning (thanks Scarecrow), you might have come to a different conclusion. It'll fluctuate over time.

The only things that are certain are that if you abort the upload (as some people have talked of doing), you won't get any credit, and the system will waste time sending out the work to be done again by somebody else.

LoL, glass empty dry for me these days, not SETI related...
And sure, no reason to abort no matter what scenario will be realised. From user side we can't do anything positive but wait, but from server side it may be worth to disable replication automation for some days (if possible) to avoid performance drop in case of my scenario.

Hi, I've already some (CUDA)task's past their deadline, 22Feb2010; 06:22, other tasks, still some running on 1 host, are in High Priority.
I think of lowering my recource share and cache, don't know if it'll help, since it (BOINC 6.10.18) is only trying to UPLoad!

[ADDED]Never seen this reply from the scheduler:
22-2-2010 11:06:19 SETI@home Scheduler request failed: Server returned nothing (no headers, no data)
22-2-2010 11:07:20 SETI@home Sending scheduler request: To report completed tasks.
22-2-2010 11:07:20 SETI@home Reporting 19 completed tasks, not requesting new tasks
22-2-2010 11:08:10 SETI@home Scheduler request completed
22-2-2010 11:08:14 SETI@home Started upload of 27dc06ac.6733.5798.14.10.52_1_0
22-2-2010 11:08:14 SETI@home Started upload of 27dc06ac.6733.5798.14.10.18_1_0
22-2-2010 11:08:40 Project communication failed: attempting access to reference site
22-2-2010 11:08:40 SETI@home Temporarily failed upload of 27dc06ac.6733.5798.14.10.52_1_0: HTTP error
22-2-2010 11:08:40 SETI@home Backing off 30 min 12 sec on upload of 27dc06ac.6733.5798.14.10.52_1_0

---

I think of lowering my recource share and cache, don't know if it'll help, since it (BOINC 6.10.18) is only trying to UPLoad!

No, it won't help. It will only affect the behavior after the results are uploaded and reported.

---