I am running a basic 3-2-1 Einstein,Seti,Rosetta (4 hr target)resource with a 3 day connect. (also leaving room for LHC when available as a 4 resource )
Rosetta always(lately) asks for work in batches and causes edf mode.(last fetch was 30 units).With it being a week deadline compared to the others it becomes dominant in edf. Then if I don't abort them it causes Einstein and Seti to miss deadlines and it won't dl again until the neg debt is small.(week or more) Is there anyway to make the server side less aggresive?Perhaps using the result duration correction factor properly? Einstein can also be over aggressive but this is maddening....and no don't ask me to connect every 0.1 days as it is not feasible. I just have to abort a bunch but seems such a waste of my time and server bandwidth.The most it should ask for is 18 units (4x6=24x3=18) Why would it load 5-6 days of work when time to connect is 3 days? Boinc debt tool shows it is lt and st negative so this makes no sense....I have been running Boinc projects for a number of years and find this current Rosetta aggresiveness to be most challenging ....Now with the request to crank it up in processing from project admin I am wondering if this is why ,and will cause me to do just the opposite...Thanks JR

---

It's this crappy BOINC preference page again that confuses many people :-(

The setting Connect to network about every 0.1 days has nothing to to with network usage. It does not mean that it will connect to the server 10 times the day.


The correct section for this option would be "Disk and memory usage" and the correct prompt would be "Try to cache work for about 0.1 days per project" because that is what it does. It does not even affect the network connect rate btw, as the hysteresis (distance between high / low water mark) doesn't change with the setting.

"Per project" is one of many bugs in the client scheduler but that's how it currently works.


A hint : if you frequently reset the project the BOINC client does not have a chance to adjust the <rsc_fpops_est> value that allows the client to learn a correction factor for the duration. So resets should be avoided.

It is not decided by the server how much work to send, the server sends what the client asks based on the reported numbers of the client. Not less not more. Probably your Result duration factor is not yet stable and your client underestimates the runtime of one WU. Did you change your runtime preference lately? Of course I would recommend reducing the cache to 1 or 2 days max as with different projects you should never run out of time, however that is your choice.

There is a beta BOINC (5.5.6) available with a supposedly smarter scheduler. Try it out:

http://boinc.berkeley.edu/download.php?dev=1

---

There is a beta BOINC (5.5.6) available with a supposedly smarter scheduler. Try it out:

http://boinc.berkeley.edu/download.php?dev=1

JM7 (the programmer of the scheduler) said this about 5.5.6

"The worst bug in 5.5.6 is that work fetch is broken..."

in this post to the seti boards.

tony

Maybe it would be better to try it not earlier than in 2 weeks then ;-)

JR, as others have pointed out, Rosetta doesn't decide how much work to give you... BOINC does. However, Rosetta has a feature BOINC was not really designed for, and so Rosetta can end up tricking BOINC. This is the WU runtime preference. When you've got a 3 day cache, and you up your WU runtime preference from the 3hr default to say 12 hrs, BOINC downloads work assuming it will only take 3hrs to crunch, and LATER "learn" that they take 12 hrs. And so you get 4 times more work then you would like.

Did you recently change your WU runtime preference in the Rosetta Preferences? It will sort itself out, but with the new 7 day deadlines for R@H, and your larger 3day cache, yes you may end up with more work than you can crunch and need to abort WUs that are missing their deadlines. It will sort itself out though once BOINC gets some WUs crunched, sees they take 12hrs, and has updated to the project, so it shouldn't be a problem going forward.

More info. and example in the QA item on download time.

---

Add this signature to your EMail:
Running Microsoft's "System Idle Process" will never help cure cancer, AIDS nor Alzheimer's. But running Rosetta@home just might!
https://boinc.bakerlab.org/rosetta/

Thank-you all for your replies :) I did recently change the run time from 6 to 2 then to 4 hours about 4 days ago but seemed to be ok until the day I posted.I also went down to 2.5 days to connect from 3. 2 is the lowest I ever run due to personal reasons related to LHC and internet.(I know it is not really time to connect but if I want 3 days in a 7 day deadline after it is 1-3 days old it will go into edf sadly even though it has time to finish so ttc more says that if a wu is 4 days old on a 7 day deadline it will DEFINATELY be in edf)(4+3 to connect=7)
I am also aware that Boinc makes the rpc calls not Rosetta,however I failed to mention that Boinc asked Rosetta for 2 seconds work in my logs when it d/l the mass of work it did so my disdain at Rosetta.As I had said Einstein will over assign work based on Boinc rpc calls also so I blame the projects and not the messenger (Boinc)
Like I said I have been running Boinc for years and it always seems to throw up some kind of tweaking challenge based on what your real wishes are.

---

One thing to keep in mind is, that EDF-mode is not an exception which should be avoided but just a measure of precaution which will trigger (unnecessary) if you have a combination of many projects, short deadlines, big caches. In fact running in EDF mode is fine and by no means inferior to running in round robin mode.

Getting BOINC to do in detail what you want is not possible without drastic measures (aborting WU, etc.) with the current design. You only can specify the project share and that's respected over the long time, what happens in the short time (switching apps, running in EDF, asking for WU, etc.) can't be reasonably controlled (this is true for all BOINC-based projects).

---