• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Can't get more WU from Rosetta...

Kelemvor

Kelemvor

Lifer
I'm trying to get my PC to download a ton of WUs so I can just crank them in case I go offline.

I have my preferences set that I connect to the internet every 7 days and to keep an additional 1.5 days on hand. I was told if we go over 10 that's bad so that's only 8.5.

Problem is it only downloads enough to have like 3 WUs queued up. These current ones I crank through in a couple hours so then it goes and grabs another one.

How can I get it to just go download lots all at once?
 
Not sure what you mean...

I can crank through a WU in a few hours. Problem is I want it to download enough for me so that I have 7 days worth of WUs queued up on my PC at a time so I don't have to keep downloading new ones all the time.

That's what *should* happen when I saw the "I only connect every XX days" option but it doesn't seem to be working...
 
I'm not sure why the client isn't downloading 8.5 days worth of work like you are telling it to, but I've never had very reliable results with that setting. My computers seem to download whatever they want to regardless of what the queue size is set to.

In your project preferences on the Rosetta site, you can tell the project that you want 24 hour long work units instead of the ~2 hour work units you are getting now. It won't affect how many work units you download, but will make them last a lot longer.
 
I tried changing to the 24 hour WUs and also changed my settings to Connected every day but keep 7 days in the cache. Not sure if it made a difference yet but I'll keep an eye on it today.
 
Sometimes you also need to take a look at the deadline of the WUs. I had a problem similar to yours with MalariControl.net. My cache was set to 5 days, but the deadline for all WUs was three days. So, the scheduler decided to not give me any but two WUs on my dualcore because it thought I wouldn't finish the work in time, as the cache was higher than the deadline. Maybe that applies for Rosetta as well.

What Philippart means is that there's a setting in your account where you can chose how long Rosetta will crunch a WUs. The Rosetta WUs do not contain a limited number of tasks, they could ponder a folding problem for ages if you want to. So, even if you can't fill you cache, for whatever reason, you can at least make sure that Rosetta will work on a single WU at least some 16, 12 or 24 hours, according to your setting.

one other thing to check. Shut down BOINC, go to your BOINC folder and open the clientstate.xml file. Look for the Rosetta part and there look for an entry called "duration_correction_factor". That number should be somewhere between 1 and 2. If that number is very high, like 7 or 10 or 15, then we got your problem.

:beer:
 
My Duration Correction Factor is: 0.273775

Rosetta has WUs be due after 10 days so I made sure that my Connect Every and my Additional Cache settings are under 9 to hopefully avoid that problem.

I went into the Rosetta setting and chance my setting to 24hours under Target CPU Run Time

So far it hasn't changed anything....
 
Did you also hit your "update" button in the BOINC client? If not, it'll take a while till your client communicates with the servers again.
 
Yeah I do that every so often from the Project Tab. Most of the time it just says Requesting 0 work though...

I did see somewhere else that over time (couple weeks maybe) the client gets smarter and will adjust what it asks for and things to try to make it closer to what I set?

Not sure but I guess we'll see.

Do you get ore or less credit per job you turn in when they take longer to crunch? Does it take that into account on whether I'm doing 2 hr WUs or 12 hr WUs?
 
Originally posted by: BlackMountainCow
Credit is reflected according to the time you crunch the WU, so no loss on that end.
Click to expand...

So what benefit is there to crunching a certain WU for 3 hours or 24 hours? Do I do a more in depth analysis if I crunch it for a full day? I'm understanding why that's something I can choose instead of I just crunch it until it's done... heh.
 
Well, it's like trying to solve a puzzle, that has a unknown number of solutions. If you ponder on the problem for 3 hours, you'll end up with the best solution you were able to get in 3 hours. Accordingly, if you ponder on the problem for 24 hours, you'll also have a best solution. Now, that doesn't mean that the 24h solution has to be better than the 3 hours solution, but maybe it is.

Same goes with the Rosetta WUs. Predicting the fold of a protein depends on so many variables (ABCDEFG), that a longer running WUs just has more time to try to alter more of these variables. Instead of sending home the results for variables ABC and telling the WU generator to create a new WU with variables DEFG only, the long running WU will also try to test DEFG within the original WU.

At east that's how I understand the Rosetta folding and WU generating process.

🙂
 
So if I only crank something for 3 hours and send it back, it may send the same WU to someone else to do more testing where I left off? But if I test for 24 hours, there might not be anything left to test (or might be depending on my PC).

If that's true, I guess that makes sense.

I'm just not sure why that's even an option then. They should set it to 24h by default and just let people change it if they don't run it enough to get that done in the 10 days.

Ah well.
 
So if I only crank something for 3 hours and send it back, it may send the same WU to someone else to do more testing where I left off? But if I test for 24 hours, there might not be anything left to test (or might be depending on my PC).
Click to expand...

That's the way I understand it.

I'm just not sure why that's even an option then. They should set it to 24h by default and just let people change it if they don't run it enough to get that done in the 10 days.
Click to expand...

The option was introduced in a time when the Rosetta downloads for crunching a WU were really large and people with slower connections just could not keep up with the up and downloads. Back then, every single WU needed a whole lot of extra input files and stuff. Also, the uploads of the results weren't compressed yet. I guess the option just stuck.
 
Originally posted by: BlackMountainCow
Sometimes you also need to take a look at the deadline of the WUs. I had a problem similar to yours with MalariControl.net. My cache was set to 5 days, but the deadline for all WUs was three days. So, the scheduler decided to not give me any but two WUs on my dualcore because it thought I wouldn't finish the work in time, as the cache was higher than the deadline. Maybe that applies for Rosetta as well.
Click to expand...
Yes, the same rules applies for all BOINC-projects, except possibly non-cpu-intensive projects, but each project sets their own deadlines and so on...

If a single project and permanent internet-connection, the client should in theory always have "N days cached". But, if you thinks a little about it, this also means each wu is "N days since downloaded" by the time they're finished crunching.

If worse-case scenario your internet-connection goes down, or project-servers goes down, just before your oldest wu is finished, if this unexpected outage lasts "N days" you'll just have enough work on hand till outage over, but by this time your oldest wu is now "2 * N days old"...

Meaning, if the reason for a large cache is to handle Unexpected Outages, it's in reality a waste of time to set it larger than 1/2 the deadline, and to have a little bit of head-room, wouldn't recommend anything more than 40%.


For Expected Outages the case is different, and a larger cache can be used.

But, then it comes to "Connect about every N days", client still treates this as the "worse-case"-scenario, meaning "connection available 1 minute before oldest wu finished" (this wu is N days old), "next connection in N days". Meaning, you'll again land in "2 * N days since downloaded".

If "2 * 'Connect about every N days' + 0.1 hours" > "wu-deadline" this means "Work-request to project blocked by client except if idle cpu"...

Atleast if you've got a permanent connection, set "Connect about every N days" to 0.1 days (or less), and use "Cache N additional days of work" instead, since this setting doesn't use the "2 * N days"-rule.

But, there is a 10% "safety-margin", to handle a little downtime, estimated run-time too short and so on. If you hits this safety-margin, work-request will again be blocked by client...



 
You must log in or register to reply here.

TRENDING THREADS

Back
Top