5,903 queued according to the homepage. Number is dropping fast too.
All my linux clients have the same messages in their log:
[rosetta@home] Message from server: No work sent
[rosetta@home] Message from server: (there was work for other platforms)

Will there soon be wu's for linux platforms?

---

Yes, more will be added soon.

Yes, more will be added soon.

Thanks for all your hard work. I've got a few left on my Linux machine and you'll probably have more well before I run out.

I do have a question. I believe the reply sent back from the scheduler is kept in the file sched_reply_boinc.bakerlab.org_rosetta.xml. In there I see this line:

<request_delay>86400.000000</request_delay>

I assume that is something set by the project. At least when I first started getting the no work available message it immediately backed off one day rather than starting low and increasing the backoff time.

If this is set by the project, would it be possible to change it from 24 hours to 1 hour?

Thanks again!

Charlie

---

-Charlie

the delay will increase with every failed connection request. i am not sure if the project can set a min value but normaly you will back off for a minute and when it fails again for 2 mins and so on... (would have to check code for exact time intervalls or how much random amount is in there, too). you can manually connect to the project though (not sure how to do this though with command line boinc)

---

--
Florian
www.domplatz1.de

the delay will increase with every failed connection request. i am not sure if the project can set a min value but normaly you will back off for a minute and when it fails again for 2 mins and so on... (would have to check code for exact time intervalls or how much random amount is in there, too). you can manually connect to the project though (not sure how to do this though with command line boinc)

That didn't happen this time. The connection never failed. It's just the project had no work. The first time it happened it immediately delayed for 24 hours. I manually updated several times over the next few hours and each time it delayed 24 hours. The fact that the delay time was in the scheduler reply file indicated it came from the scheduler, so I figured it was something that could be set by the project.

I have seen failed connections where it starts at a one minute backoff and gets progressively larger, but that is not what happened this time.

Charlie

---

-Charlie

No problems on three computers which get only one job at a time. Trying large downloads? I believe a limitation has been added.

---

Vester, It's strictly Linux, my 3 Linux machines are all waiting around for 24 hours for another job to come down the pipe.

I also believe it should be reduced to 1 hour, maybe 2, but having a machine sitting around for 24 hours when work may have been available for 23.5 hours seems a bit wasteful.

---

That didn't happen this time. The connection never failed. It's just the project had no work. The first time it happened it immediately delayed for 24 hours. I manually updated several times over the next few hours and each time it delayed 24 hours. The fact that the delay time was in the scheduler reply file indicated it came from the scheduler, so I figured it was something that could be set by the project.

I have seen failed connections where it starts at a one minute backoff and gets progressively larger, but that is not what happened this time.

Charlie

oh, i see. (after rereading your original post again I could have concluded that you are not affected by the behaviour I described, my bad)

---

--
Florian
www.domplatz1.de

@David: all clients running fine now, many thanks !

@Vester: 0.9 days of work is hardly a large cache :) Moreover, since the resulting cache is based on the RAC, and this RAC is building up as youcrunch, it's far less then 0.9 days (in my case).

The fact it defers connections for +- 24h at once when the server responds with "no work from project" is indeed cumbersome ... I now have all my inux clients run the "boinc_cmd --project https://boinc.bakerlab.org/rosetta/ update" command every hour, just to make sure they have work (and that they report the results). That can hardly be the purpose of the 24h delay.

---