Ingleside,

One last time on this, so I'll be able to compile a functional FAQ of "Dont send me repairs/short deadline jobs", but still Beta and Dengue A type????????:

You've not said it now nor in past: Does this function require for the Network based on preferences to be selected... before the moans come it does not work if "Network always available" and is that behaviour consistent through all versions?

A-type needs reliable, and with "Connected..." > 4 days chances are your average turnaround-time is larger than this, so you won't get them... But, if your average happens to be less than 2 days so your computer is "reliable", you can get them as long as the reduced deadline is 8 days and your "Connected..." < 8 days.

As for beta's, beta's isn't reliable, so this depends on the deadline. If deadline is 3 days (normal for beta?) you won't get them with 4-days setting.


Network "based on preferences" or "Always" doesn't matter.

The only things that matters (appart for the off-chance a project disables all deadline-checks, something AFAIK no project has done...) is:
1: Client has atleast one wu in project either in progress or cached.
2: The estimated run-time (depends on benchmark, DCF and so on).
3: The "Connected..."-setting.

If #1 is zero, no cached work in project, you can get a wu regardless of has any hope of returning this wu by deadline or not.
Hmm, apparently this is client-dependent, in v5.10.45 your estimated_delay > 0 if got atleast one wu in project on multi-cpu, but in v6.11.6 estimated_delay > 0 only if got one wu per cpu...
#2 depends on client, since depends on estimated_delay, and resource-share and so on can be reported differently depending on client.
#3 is client-independent, well except if you've got an old v3-client...

The actual code goes like this, with my own comments:

if (get_estimated_delay(bav) == 0 && !hard_app(app)) return 0;
// By-pass the deadline-checks if no work on client in project,
// except if hard_app, but AFAIK only Astropulse is "hard_app".

if (config.workload_sim // more code
// AFAIK only BOINC alpha has ever used this code.

// "Normal code":

double ewd = estimate_duration(wu, bav);
if (hard_app(app)) ewd *= 1.3;
doublet est_completion_delay = get_estimated_delay(bav) + ewd;
// calculates estimated run-time based on benchmark and so on.
double est_report_delay = std::max(
est_completion_delay,
g_request->global_prefs.work_buf_min()
);
// In other words, whatever number is highest of the estimated run-time and "Connected..."
double diff = est_report_delay - wu.delay_bound;
if (diff > 0) {
// Game over, based on the calculations you won't return this wu before deadline,
// either due to too long estimated run-time or too high "Connected..."
// (whatever is largest), and therefore you won't get this wu.

@Dena

Sorry for not looking into it earlier. Your computer now has an 'average turnaround' of 7.28 days. This will prevent it from being sent any more high priority results. Due to it being a 'power mac' the reliable guidelines are much looser since there are so few of them around. As a result your computer was identified as a 'reliable' host longer than expected (which in turn kept your turnaround time low). However, now that you have moved outside of the reliable range you will not get sent any more high priority workunits and it should work as desired.

FYI - the average turnaround time required for a Power Mac to be flagged as reliable is 3.6 days vs 2 days for all other computers.

For other users with this problem, I suggest you do what I did to clear the problem. I set no new task for WCG until I was down to a few work units to process. I then turned off no new task till I had a fresh batch of work units then I turned on no new task again. This allows the work units to be processed and returned as slow turn around work units and after a few cycles the turn around time will be adjusted to reflect the true values for your system. I am now at the point where I can allow work unit demand to be managed by Boinc without manual intervention.
I still feel it's a bad idea to treat repair units different that other work units. People will adjust their program to avoid them and that will result in fewer people to process them. If a decision is made about who receives repair units, the decision should be made on who alway returns units instead of how fast the work units are returned. Also repair units should also be sent with the full measure of time so users will not want to avoid them.

Hi Kevin, I'm sure you/someone will have already thought about this suggestion in the past, so I'm just adding it into the mix so that it's documented - what about a 'reliable host opt out' button?. That way, for whatever reason, someone can opt their machine out of receiving repair WU's ever again (of course, the default would be 'opt in'). Perhaps, it could work similar to the Beta WU function - only this time, in reverse?