How long have they been in this state? A short while (hours, up to a day) is perfectly normal. There is nothing you need to do in that case.

If it is longer than this, then please click on "Update" in the project tab, then check the Messages tab. Post the messages here if there are problems.

I don't follow, Johnny. The delay has no effect on the credit you earn, only the time when you get it. In practice, this means that there is a ramp-up period when you start crunching, but while you are crunching continuously, you get a continuous (and fairly steady) stream of validated work.

You can try to report earlier, but this has no effect if your quorum partners don't return work promptly. So, this is why I think trying to optimise the return time is a futile effort.

However, I know people like to tweak and tune, so I will share what I know. Firstly: don't do forced updates or use the immediate return feature. It's rude, because it puts extra strain on the already heavily loaded servers. Instead, tune by reducing your network connection interval, and using the work buffer to control your queue.

Seriously, you say "I am somewhat frustrated at not being able to send in results in a more timely fashion." This isn't your problem. When WCG want results in a hurry, they set a short deadline. For normal work units, they are perfectly happy to wait.

You don't have to baby-sit work units. Just, in the words of Lennon/McCartney: Let it be.

edit: Faster reporting won't lead to a quicker cure. WCG has work delivered in batches, and return the complete batches to the scientists. The whole batch is limited by the straggler work units that need extra copies to be sent out. When the scientists want work done in a hurry, then WCG can prioritise it over other batches, and adjust the deadlines to get it back quickly. They have done this at least once.

Thanks for the replies, Didactylos and Sekerob.

Sekerob, my settings for ""Connect to network about every 'x' days" short," are:

Connect to network about every .03 days
and Cache 1 extra days of work.

Is that reasonable? In another thread, you posted .03 days.

Thanks all!

JC,

Don't know in what context I typed that, but sounds like a typo as 0.3 was the default (7.2 hours), which was a number set to bridge the somewhat longer outages of longer history.

What is your strategy? 0.03 is as good as any small value. Effectively, the scheduler looks if there is in your case, 1 day and 43 minutes in buffer based on current efficiency. If not, it fetches X seconds to fill it up (not precisely as BOINC has safeties, but lets keep the logic simple). Since there is never exactly a requested amount of work on offer, a call for 10,000 second of work or 1,000 seconds will result in a whirring and a plead for 1 job or 2, which is maybe 20,000 seconds or 30,000 worth, all depending on the particular machines current efficiency record. It wont be calling for work again until it's close to the minimum again. If in that period a job finishes and the 1 day, 43 minutes has not been reached again, the scheduler will return only the Result file to a separate database and on next call for work, send the "Ready to Report", causing only 1 scheduler computation.... i.e. you see Requesting X seconds of work and reporting 1 completed task.".... on and on.

Now if you set the connect period to 1 day 43 minutes and the cache to zero, you get quite a different work call and reporting activity.... saved for the next installment, but here there is a good chance you have several of these pesky RtR's sitting around testing your patience....

There's no "One Size Fits All", but please don't change things too often or you find a very confused BOINC needing a project reset.