Not asking for work seems to be the easy one in your instance...

If you've got more than 2x #cores uploads in a BOINC project, regardless of upload being in progress or waiting, work-request to this project is blocked until enough uploads has been finished.

As for project-backoffs for failed work-requests, if you fails connecting to project-server at all, you'll get a normal random backoff, between 1 minute and 4 hours, just like before. This backoff shows-up in BOINC Manager.
If you on the other hand connects to server, but doesn't get any work for a work-request, you'll also get a random backoff. This backoff has upper bound 1 minute for 1st. failed request, and upper bound is doubled for each successive failed work-requests, upto a max of 24 hours. How long this backoff is will be shown if you select the project, and hits "Properties". If you hits "Update", or if a task in project finish, this kind of backoff is zeroed-out...

For uploads, you'll have the normal random backoff between 1 minute and 4 hours. There's also a new option, the project-wide backoff. In case of 3 failed transfers in a row, the project gets a similar random backoff.


But, these backoffs will only happen if you've got connection-problems. If you've permanently connected, uploads should happen immediately as tasks finish, just like in older clients.

I'm not aware of WCG having any connection-problems, so if re-booting any modems and so on and re-booting computer doesn't solve your connection-problem, you'll need to give more info...

I have finally worked out what's going on. Thanks Ingleside, but the problem is not a back-off one - 6.10.58 does not poll for incremental additional WU's as the earlier version did - that version would poll the scheduler for XX secs work and receive a few WU's and then go through the same routine again a couple of hours later after completing another WU or two - the new routine seems to be that the finished WU's will be reported but the downloads are only coming 2 or 3 times a day and then between 10 and 15 units at a time.... and multiple WU's from a single project - I have just had 7 x C4CW, 5 x HFCC and 3 x CMD appear (21.00) as a single batch, with 2 x C4CW, 2 x HFCC and 6 x CMD at 06.00 this morning, also a single batch.

This reminded me of this other thread, which BTW still affects one of my PCs from time to time.

Suggest to set in the Activity menu the Network briefly to Suspended and then back to "Network activity always available". Maybe a stuck bit... had it some months ago where it was constantly flip-flopping by itself.

If it's not too much trouble, please go through the stdoutdae.txt file to see whether anything is logged then also set in the cc_config.xml the log_flags

<network_status_debug>1</network_status_debug>
<work_fetch_debug>1</work_fetch_debug>

For info and instructions see: http://boinc.berkeley.edu/wiki/Cc_config.xml

In the advanced menu you can read in the config. Log flags do not require a client restart.

Believe it was mitrichr who found that quite some months ago that the cache would fully deplete on his hyperthreaded quad and cores idling unless he set the cache to 2 days **. With 2 days you get Ready to Report being forced up since they will when older than 24 hours. Not sure, but maybe the GPU scheduler is part of the problem. I've got that function disabled with the <no_gpus>1</no_gpus> option in cc_config.xml

Can everyone confirm it's that the Transfer tab shows file to upload in this situation.

JSYKES, please expand on this bit "The only way I can get the upload going is to log on to the WCG website". You mean you have to sign in to WCG?

thanks

edit: I've been running 6.10.58 for long and not experienced this. When WCG came out with their custom kit, installed that over and not observed any behavioral changes.

** Cant remember if the Result files were uploaded and it simply being the question of no work being fetched. In that also please flip flop the Work fetch to No New Tasks and back to Allow New Tasks.