My message log shows that BOINC is repeatedly requesting small numbers of seconds of work from rosetta@home: 1373 seconds, 1292 seconds, 2672 seconds, and 2600 seconds are the most recent ones - only 43 minutes! The reply is "No work from project" - is that because there is no work unit with such a short expected run time? By comparison, BOINC last requested 17280 seconds of work from seti@home (288 minutes, 4.8 hours).

Does the server really consider the number of seconds' work you request when deciding whether to send new work, or what to send?

---

I think if you`re running two projects or more it try`s to work out that you get no more than that so not to make the other go over the deadline.

---

Not all Czech`s bounce but I`d like to try with Barbar ;-)

Make no mistake This IS the TEDDIES TEAM.

The number of seconds is based in part on the connect interval. But, also on what you can do based on machine characteristics.

If you ask for one second you will get at least one work unit. Ask for more and you will get more ... maybe.

No work from project is another problem ...

---

Thanks for the insight. Glad that asking for even one second will give me work.

Should I configure something to ask for more work, so I have more jobs queued up during the more-and-more-frequent server downtimes? Right now I'm not getting work from rosetta@home *or* SETI@Home ... all those cycles going to waste.

rosetta@home shows all servers running on the server status page, but all of my client requests are being met with "No work from project." (SETI@Home gave me that answer for a while today, but now it's not answering at all.) Any thoughts?

---

I increased my cache size (connect to network every x days in preferences) to compensate for no work being issued on RPC. It's worked out pretty good for me so far, I have it set to 1 day now.

---

I have a somehow equal problem. I have 2 Clients that should crunch Rosetta mainly. I set Connection time to 5 days because i have dial-up. So the CC is requesting 117870 seconds (32h) of new work but only gets 2 WU (12h). After 10mins it request the same amount of new work but only gets 2 WU.

The second Problem is because my Client is faster than BOINC is expecting. I crunch one Rosetta-WU within 1.5h and not 6h so my 3days cache runs low within 12h. Until i can switch on Internet next time the Client has no work.

I tried to attach to another project to compensate the lack of work from rosetta but that had no effect because my long-term-debt for rosetta is very high and so the CC is not downloading any other work.

As a workaround i pause rosetta from time to time to let the other Project get work. But thats not what i want. I want to have work for 5 Days within 1 Request. The only project where this works great is Seti@home (ATM).

Some Infos at the end:
BOINC Client 5.2.15
Windows 2000 SP4
Running 24/7

---

BOINC Doc | Team-Site | BOINC-Podcast

I have a theory about rosetta@home and work units: I get the impression that those work units are more variable in how long they take to execute, and the project has less experience predicting their duration. Thus, the server *thinks* it's sending you 32 hours of work, but you run through it in less time.

The whole cache system is based on the work-unit/time predictions. I wonder whether there's an automatic feedback system for improving the predictions based on the historic number of cycles that "similar" WUs have consumed. If not, it could prove worthwhile. Of course, this still leaves the question of what WUs are "similar" to others in a project that's running multiple different algorithms like rosetta@home does.

Just a thought.

---

There is a feedback system to adjust the expected time to completion, look for duration correction factor in the wiki. It usually takes about 10 tasks to get an accurate estimate. It is also designed to adjust to longer than expected estimates more quickly than shorter ones, because an overestimate is annoying to one person but an underestimate can cause problems for several.

Another possible source of your problem is in the deadlines. With a 5 day queue the deadlines need to be at least 12 days for everything to work properly. Deadlines here are currently 7 days, so anything over 3 days queue is likely to cause problems. The general formula for maximum desirable queue length is 40% of the shortest deadline divided by the number of projects. I realise this is not very helpful Diango, sorry.

---

BOINC WIKI

BOINCing since 2002/12/8

There is a feedback system to adjust the expected time to completion, look for duration correction factor in the wiki....

You are correct that this is the value that needs adjustment. But you are equally correct that if you set it too short you will get so much work that you could not possibly complete it before the deadline. The DCF can be adjusted manually, but as you point out it will adjust (readjust) itself over time.

It seems to me that the real problem here is the variability of the length of R@H WUs, coupled with a lot of folks who are trying to run long queues. Over the last month the variability of the WUs has increased to the point where the longest can exceed 25 hours and the shortest run in about an hour. The project admits that they are having a difficult time prejudging the WU time estimates, partly because of the different types of systems in the client pool.

I don't think that there is an easy solution for any of this. Those of us that are fortunate enough to have a constant connection with unlimited data flow for a fixed fee, seem to have the least trouble. Mostly because we can set the queue to a day or less and let the system run itself. Those less fortunate on their connections, are having to tinker with the systems a lot to keep them busy and running. It is a shame it is that way but the project kind of has to shoot for the middle and hope for the best.

Thank you for your Response. It gave me some good hints whats going on. In the meantime i had detached all other Projects except Rosetta at my Computer here cause this one has permanent Internetaccess (on workkdays). I hope it will collect enough work to get over the Weekend.
So far i got enough work for 5 Days (says BoincView) but the CC got into critical EDF mode and is not downloading work any more. Lets see whats going on in the next days.

Btw: The duration-correction-factor seems to get better now.

---

BOINC Doc | Team-Site | BOINC-Podcast