I can meet the deadlines.

That's good, but a bit surprising if you hold a 7-day buffer but half the tasks have a deadline of 2 or 5 days rather than the more usual 14 days

I am running BOINC on Linux machines headless. After updating /etc/hosts with 128.95.160.145 srv1.bakerlab.org they still weren't able to upload recent work. I control BOINC through boinctui but couldn't find a way to force retrying of upload. The solution I found was to restart BOINC after the hosts file edit, then the uploads retried, and successfully uploaded. On a recent Debian system or derivative (Ubuntu and more), BOINC is restarted from the terminal by running sudo systemctl restart boinc.

$boinccmd --get_file_transfers

$boinccmd --file_transfer http://boinc.bakerlab.org/rosetta $filename retry

$boinccmd --set_network_mode never
$boinccmd --set_network_mode auto

Without making any changes to any hosts files and simply waiting (While still crunching at least), all my completed tasks finally uploaded and I got credit for them. Looks like they fixed it.

99% of the users will forget that they have made this change an will later have another problems only caused by this solution!

..., we're all on the same team here man :)

No! That is wrong, they need us, we don't.
They get money for the job. I spend money, for hardware and for power. I spend my spare time for maintenance of my systems to keep them always crunching.
Later, in an hopefully no so far future, if the first results come to the market, pay i again to get the medicine or whatever.

Change of hosts.txt is a stupid idea! There should be another way.

Replace of "srv1.bakerlab.org" in client_state.xml is useless. Whenever i restart the boinc manager is it again there. I can't find from where boinc restore this.
i have it also replace in client_state_prev.xml.

Thanks your lazy guys have i now two WU's lost! 24 hours of work for nothing.

Thanks Timo! I just tried it and it works for uploads.

Here is the line to add to Windows hosts file to work around the server that is not responding. If you don't know what to do with this information, it would be best to just wait for the issue to be resolved on the server side.

128.95.160.145 srv1.bakerlab.org

<upload_url>http://srv1.bakerlab.org/rosetta_cgi/file_upload_handler</upload_url>

<upload_url>http://srv4.bakerlab.org/rosetta_cgi/file_upload_handler</upload_url>

23-Jun-2016 11:45:49 [rosetta@home] Started upload of FFD__462b8a0655b364e9452ad1a759651ef7_abinitioDocking_16_06_16_35_36_globalDocking_4_SAVE_ALL_OUT_383173_1_0_0
23-Jun-2016 11:47:49 [---] Project communication failed: attempting access to reference site
23-Jun-2016 11:47:49 [rosetta@home] Temporarily failed upload of FFD__462b8a0655b364e9452ad1a759651ef7_abinitioDocking_16_06_16_35_36_globalDocking_4_SAVE_ALL_OUT_383173_1_0_0: transient HTTP error
23-Jun-2016 11:47:49 [rosetta@home] Backing off 04:19:42 on upload of FFD__462b8a0655b364e9452ad1a759651ef7_abinitioDocking_16_06_16_35_36_globalDocking_4_SAVE_ALL_OUT_383173_1_0_0
23-Jun-2016 11:47:51 [---] Internet access OK - project servers may be temporarily down.

Solution: Drop the support for smartphones and tablets and concentrate on enabling AVX2. This should have a much higher priority.

22-Jun-2016 14:51:23 [rosetta@home] Scheduler request completed: got 0 new tasks
22-Jun-2016 14:51:23 [rosetta@home] No work sent
22-Jun-2016 14:51:23 [rosetta@home] Rosetta Mini for Android is not available for your type of computer.
22-Jun-2016 14:51:23 [rosetta@home] (won't finish in time) BOINC runs 81.4% of time, computation enabled 72.7% of that

22-Jun-2016 15:35:14 [rosetta@home] Scheduler request completed: got 25 new tasks

Maybe they need the results ASAP, so they force "high priority" on client side. Also got one of them, not a real issue, unless someone just planned to turn his machine off for a couple of days.

EDIT: or this might be their way to fix something else.

Both of those WUs came from jobs that got cancelled by the researcher (see here and here - note the 'errors' field shows the job was cancelled) after your received the WU in your queue. Generally if you wait a couple of days the claimed credit will be granted on a future sweep of the validator program.

Situations like this are why David has been looking at tightening up the required 'average TAT' for some jobs. It doesn't appear to me that the BOINC client/server supports any kind of 'remote kill switch' for a given WU once it's been downloaded, so there's no way to prevent said WUs from needlessly running after queued if the job they belong to gets cancelled

Personally, to improve my average turn around time for my boxes and thus increase the chance that the crunching I'm doing is actually going to contribute to someone's query results, I've actually tightened my queue settings (I basically don't queue any tasks) and my target runtime is a more modest 8 hours.