Communications aren't suspended, only work-request.


This behaviour is mainly a safety-feature, to guard against client becoming overloaded with work it has no hope of returning by the deadline. Since client has no idea of why user is suspending tasks, continuing asking for more work is dangerous, since if user resumes the paused tasks client can be hopelessly overcommited. If the suspension is due to something that looks like a problem with tasks, but later after checking the forums shows isn't really a problem, client can again be hopelessly overcommitted.

Also, before this feature was added, more than once users had forgotten to resume tasks...

There's also some other reasons for the addition of this feature, some of them aren't so important any longer due to other features being added later on. Still, two that is still in effect is to make it harder for users "cherry-picking", or users just continuing downloading work for afterwards just ditching it.

The order to push jobs, assuming your tasks few view is FIFO sorted:

1) suspend ready to run tasks from below the running tasks till the one before the one you wish to run.
2) suspend a running task, as many as needed to force start of 1 or more priority selected jobs.
3) Resume the suspended task(s) **, the bit that skgiven did not [forgot] to do until it was too late and his client idled.

There's different ways to do this, but I'll leave the members to write it up, and if glossy enough I'll copy-post it into the FAQ's

edit: ** The resume will set the interrupted tasks to "waiting to run" state.

Beta's or regular jobs processed and returned too late get credit for points/time/results. There's an unofficial grace period for No Reply tasks, until one day too many start planning with grace periods... it should be the exception, not the rule!

edit: and it seems my metaphor missed to hit.... when rounds were already fired, as in the job started, there is no mission abort, unless the jobs are known to be bad.

This isn't a problem, since there's two kinds of server-aborts, the normal one won't abort started tasks.

There's also an unconditional abort, but this is only used in case wu has errored-out, project has manually cancelled the wu, or it's so long after deadline that can't be validated anyway.

edit - slow typer...

The result file uploads, part 1 of the process and the Ready to Report aka RtR, part 2 of the process, are held in different parts of the DB. The RtR causes material server scheduling activity. If it were immediate with the result files, presently 450,000+ times a day, very high load, thus for efficiency sake these RtR's are held up to 24 hours, so to combine with for instance a work request that affects the same Server Scheduler. A combined RtR + work request halves the load. There are more client scheduler conditions when a RtR gets reported btw... 7 or 8. For that see the famous FAQ's.