yup, it looks like the setting I was attempting to use to get around this problem has caused nothing that needed reliable to get sent. I have pulled the setting but it has a pretty large backlog of results needing reliable. I am going to let it run for a bit to see if it can clear on its own, if not I will give it a little bump to help it.

Thanks,
-Uplinger

The setting for reliable host is what controls the 40% cut down in the rate. Yes, a reliable host is required, because the chances of them returning the work unit and helping a batch average completion time down is highly desirable. If we removed reliable hosts on a project it goes from an average batch turn around of 12 days to 21 days. Thus meaning 99% of the results are sitting around on our servers waiting for that one last result. Basically if you returned a workunit within 6 hours of it getting issues, and user B just never runs it at all. Do you want someone with a machine that consistently returns valid work on a regular basis to help complete the workunit? In our case, yes.

Hope this helps explain the reasoning behind the setting.

Thanks,
-Uplinger

Sorry, my post landed in the wrong thread. It was targeted for the 'waiting to be sent' discussion in the ugm forum. For the zero redundant you'd want a reliable host, but, does an error not throw a 2 part question as in, was the host at fault or was there something with the task? Either way, have moved way past the 'waiting for wingman'. It's really only your -problem- of maintaining server performance / storage demand and the size of the batches you choose before they are complete for assimilation in my simple view.

Did the '12 days or 21 days' refer to the 7 day deadline projects or the 10? With 7 days due you already have 2 repair cycles of 2.45 days included. What are the chances of these not coming back in their allotted time i.e. i'd think a batch would complete in 12 days for ugm and mcm either way as the agent will prioritize, and these are the 2 with the large result files going back to wcg. When nodes have a buffer of greater than deadline, the server seems not to sent these tasks to those hosts anyhow, reliable rated or not.

Maybe this is not my/the volunteers problem either, but just wanted to give outside feedback. It goes back to your feeder dumping > 47 short deadline fahv onto my tablet when there was no hope in heck to get them all done even when running 24/7, which it doesn't. It has a 7.3% error rate at that, not exactly 'reliable'. In fact in the end deleted 15 of them. Was not going to wait for the server to distribute additional copies at deadline and my tab starting them and duplicating effort in the race of 'who completes and reports first' with the additional wingman after the no replies. Loath that. Really would like the servers simply instructing agents to abort any overdue results and do away with this waste issue. Do not wait for a 'No reply' to still come back and then hope one or the other node connects and receive the 'server abort, no longer needed'. Agents can wait up to 24 hours to connect by themselves to report results i.e. overdue will get crunched till then.

New scheduler, new switch

World Community Grid 11/10/2014 11:53:10 PM [sched_op] CPU work request: 4447.15 seconds; 0.00 devices
World Community Grid 11/10/2014 11:53:15 PM Scheduler request completed: got 0 new tasks
World Community Grid 11/10/2014 11:53:15 PM Project is temporarily shut down for maintenance
World Community Grid 11/10/2014 11:53:15 PM [sched_op] Deferring communication for 00:27:31
World Community Grid 11/10/2014 11:53:15 PM [sched_op] Reason: project is down

FYI, just took a look at the loads on the system, and members may get backoff due to high usage of the system. This is due to a defrag we are doing on one of the large filesystems. It is making the IO slow across the system and should be cleared in the next hour.

Thanks,
-Uplinger