THIS IS A TEST PROJECT. THERE WILL BE NO WORK UNITS AVAILABLE AT TIMES. THEY GET ISSUED WHEN NECESSARY FOR TESTING. PLEASE SET THE RESOURCE SHARE LOW FOR THIS TEST PROJECT SO PRODUCTION PROJECTS GET HIGHER PRIORITY

This project is not for science, credits, or other competitive statistics, but only for testing to make our production project, Rosetta@home, better.

There is a bug IMHO in the BOINC client that leeds to a request for far too much work for low ressource projects (esp. after a project ran "dry" of WUs). Is it possible to change the server for RALPH so that only one WU is distributed, ignoring the seconds the client asked for? This would prevent those "large cache by accident" and would give you shorter turnaround times.

Norbert

---

THIS IS A TEST PROJECT. THERE WILL BE NO WORK UNITS AVAILABLE AT TIMES. THEY GET ISSUED WHEN NECESSARY FOR TESTING. PLEASE SET THE RESOURCE SHARE LOW FOR THIS TEST PROJECT SO PRODUCTION PROJECTS GET HIGHER PRIORITY

This project is not for science, credits, or other competitive statistics, but only for testing to make our production project, Rosetta@home, better.

There is a bug IMHO in the BOINC client that leeds to a request for far too much work for low ressource projects (esp. after a project ran "dry" of WUs). Is it possible to change the server for RALPH so that only one WU is distributed, ignoring the seconds the client asked for? This would prevent those "large cache by accident" and would give you shorter turnaround times.

Norbert

Norbert:
Actually it is not a bug it is just part of the production environment that is not compatible with a testing environment. While your point is well taken and the suggestion is a good one, It might not be so simple to implement. I will send the idea along to the project.

The problem (and what prompted David Kim's post) is that many people will join any BOINC project that comes along without reading the project goals or the FAQs for the project first. Then when it does not run like a production environment, they start posting that there is a problem when in fact there is not. So even if the project takes your suggestion, and they might, people will then wonder why they cannot have all the WUS they want.

However, I agree with your view of this. People should get say, five WUs at a time and can't get more until those are reported back. This would distribute the WUs across more clients and produce better test results on more machines.

---

Moderator9
RALPH@home FAQs
RALPH@home Guidelines
Moderator Contact

Hello. First, I feel sufficiently bludgeoned with the concept that this is a test project and there will be times there are no wu's. I am just unfamiliar with the note below and I'm concerned I may have screwed up my prefs or something. Of course, this note could be that there aren't any wu's available...;-} I have read the faq's, the boinc wiki, and all the threads on these boards without seeing anything that looks like an answer to this issue. I joined ralph 2 days ago and have yet to get a wu (again I say that's ok if normal, just doing a quick sanity check).

2/20/2006 2:03:03 PM|ralph@home|Sending scheduler request to https://ralph.bakerlab.org/ralph_cgi/cgi
2/20/2006 2:03:03 PM|ralph@home|Reason: Requested by user
2/20/2006 2:03:03 PM|ralph@home|Note: not requesting new work or reporting results
2/20/2006 2:03:08 PM|ralph@home|Scheduler request to https://ralph.bakerlab.org/ralph_cgi/cgi succeeded
2/20/2006 2:22:33 PM||request_reschedule_cpus: project op

I am running only rosetta and ralph on this cpu.
rosetta is set to 100 and ralph is set to 10 (resource share)
I have 41 rosetta wu's cached (too many, I've set rosetta to no new work until I clear some of the backlog out - I am set to connect every 3 days)
everything else is set to defaults, I think.

[edit]boinc 5.2.13[/edit]

Thanks in advance.

---

"Be all that you can be...considering." Harold Green

Thanks in advance.

Jim, I don't know how long your machine takes to do 41 rosetta wus, but I'd say it's likely the scheduler is already satisfied with the quantity of work on hand (from any project) and has entered a "no work fetch" mode. You might see that in the message log somewhere. It might be far back. At some point you should see a message "resuming work fetch" and then a request to what ever project is next up.

tony

Thanks in advance.

Jim, I don't know how long your machine takes to do 41 rosetta wus, but I'd say it's likely the scheduler is already satisfied with the quantity of work on hand (from any project) and has entered a "no work fetch" mode. You might see that in the message log somewhere. It might be far back. At some point you should see a message "resuming work fetch" and then a request to what ever project is next up.

tony

I had a sneaky suspicion it might be something like that. My goal is to have about 3 days of work cached, but I think I'm slightly beyond that now. Reviewed the stdoutdae.txt and see a number of "Suspending work fetch because computer is overcommitted" and "Allowing work fetch again" in several variations, so I guess I'll wait a few days to see if clearing my stock has any effect.

Thanks!

---

"Be all that you can be...considering." Harold Green

Thanks in advance.

Jim, I don't know how long your machine takes to do 41 rosetta wus, but I'd say it's likely the scheduler is already satisfied with the quantity of work on hand (from any project) and has entered a "no work fetch" mode. You might see that in the message log somewhere. It might be far back. At some point you should see a message "resuming work fetch" and then a request to what ever project is next up.

tony

I had a sneaky suspicion it might be something like that. My goal is to have about 3 days of work cached, but I think I'm slightly beyond that now. Reviewed the stdoutdae.txt and see a number of "Suspending work fetch because computer is overcommitted" and "Allowing work fetch again" in several variations, so I guess I'll wait a few days to see if clearing my stock has any effect.

Thanks!

Jim,

If you are running the new Rosetta Application, you can speed up the dumping of the work cash by adjusting the time parameter in your prefs. If you are still running the old version, you will just have to wait, because BOINC has already tagged the version of the application to the WUs, and you cannot change that easily (there is a work around if you want to change it early, but PM me at the Moderator contact e-mail if you want to do that.)

As for the RALPH Wus, you are not crazy, there are not any to be had at the moment. This may change soon. You will have to be mindful that some of the settings for RALPH may cause you trouble with Rosetta WUs. So feel free to ask questions and a lot of folks will jump in to help you out.

---

Moderator9
RALPH@home FAQs
RALPH@home Guidelines
Moderator Contact

Thanks in advance.

Jim, I don't know how long your machine takes to do 41 rosetta wus, but I'd say it's likely the scheduler is already satisfied with the quantity of work on hand (from any project) and has entered a "no work fetch" mode. You might see that in the message log somewhere. It might be far back. At some point you should see a message "resuming work fetch" and then a request to what ever project is next up.

tony

I had a sneaky suspicion it might be something like that. My goal is to have about 3 days of work cached, but I think I'm slightly beyond that now. Reviewed the stdoutdae.txt and see a number of "Suspending work fetch because computer is overcommitted" and "Allowing work fetch again" in several variations, so I guess I'll wait a few days to see if clearing my stock has any effect.

Thanks!

Jim,

If you are running the new Rosetta Application, you can speed up the dumping of the work cash by adjusting the time parameter in your prefs. If you are still running the old version, you will just have to wait, because BOINC has already tagged the version of the application to the WUs, and you cannot change that easily (there is a work around if you want to change it early, but PM me at the Moderator contact e-mail if you want to do that.)

As for the RALPH Wus, you are not crazy, there are not any to be had at the moment. This may change soon. You will have to be mindful that some of the settings for RALPH may cause you trouble with Rosetta WUs. So feel free to ask questions and a lot of folks will jump in to help you out.

My current app is 4.81. No need to frisky and work around it; I'll just wait a day or two untill my stash is lower. I'm keeping ralph on, so if wu's come out hopefully I'll get them in good time. Thanks for the help, and keep up the good work.

---

"Be all that you can be...considering." Harold Green

There is a bug IMHO in the BOINC client that leeds to a request for far too much work for low ressource projects (esp. after a project ran "dry" of WUs). Is it possible to change the server for RALPH so that only one WU is distributed, ignoring the seconds the client asked for? This would prevent those "large cache by accident" and would give you shorter turnaround times.

Norbert

Norbert:
Actually it is not a bug it is just part of the production environment that is not compatible with a testing environment. While your point is well taken and the suggestion is a good one, It might not be so simple to implement. I will send the idea along to the project.

If you have a host, that crunches e.g. for Rosetta 90% and for Ralph 10%, if there is new work for Ralph it will ask for 86400 seconds of new work (at a setting of 1 day connect time). The client or the server would have to make that 8640 seconds (= 10% of a day). Now both parts rely on the other side to do this calculation, but it is done nowhere. I'd call it a bug.

Norbert

---

Dumdidum......
Still waiting for the first Unit to crunch.....

These do take awhile to crunch. My first WU took about 8.5 hours or so an Athlon 64 here... Not sure what others might see, but if an older comp I imagine it could be much longer. It did go though...

As to the unavailable WUs some have mentioned, it's just something to wait for, and check the server status periodically (for a time to manually request work). As I've been running LHC for awhile, not entirely un-used to it. Though LHC is a production project, delays between the release of new batches of work isn't uncommonly. Last Tuesday or so, they had no work, then they had a blip of like 200,000+ WUs, and they're outa work again. Quicker this time then in the past, but it happens.

Does give one time to crunch other WUs also, which is how many at LHC think of it...

---

There is a bug IMHO in the BOINC client that leeds to a request for far too much work for low ressource projects (esp. after a project ran "dry" of WUs). Is it possible to change the server for RALPH so that only one WU is distributed, ignoring the seconds the client asked for? This would prevent those "large cache by accident" and would give you shorter turnaround times.

Norbert

Norbert:
Actually it is not a bug it is just part of the production environment that is not compatible with a testing environment. While your point is well taken and the suggestion is a good one, It might not be so simple to implement. I will send the idea along to the project.

If you have a host, that crunches e.g. for Rosetta 90% and for Ralph 10%, if there is new work for Ralph it will ask for 86400 seconds of new work (at a setting of 1 day connect time). The client or the server would have to make that 8640 seconds (= 10% of a day). Now both parts rely on the other side to do this calculation, but it is done nowhere. I'd call it a bug.

Norbert

The problem is that BOINC does not recognize the Rosetta time parameter either on the server or the client. According to David Kim, they can do some of the calculations on the server side outside of BOINC to guage the downloads to the actual time available on the client, but some of the internal BOINC variables and hooks that must be adjusted to actually fix this are not available to the project to to reset so they can actually make it happen on either end of the process. The project has reported to the BOINC devs whaat they need and it is my understanding that they have agreed to put it in. So the fix is coming, but there has been no commitment for a specific time from BOINC devs.

---

Moderator9
RALPH@home FAQs
RALPH@home Guidelines
Moderator Contact