The Server Status page currently says that the validator is not running.

I've EMailed the Project Team pointing this out. Thanks for pointing it out.

Hedera, you can tell BOINC to "snooze", or limit it to less then all of your CPUs, or put a memory constraint on it to help keep it responsive for you. Most likely, as you already seem aware, you are bottlenecking on memory. Yes those RNA's do that a lot. And so it you limit the amount of memory BOINC is allowed to use, it will basically scale back on how many it's trying to do at the same time.

Update: we've tracked down the problem -- its an issue with the BOINC-provided API (I guess we happened to be unlucky in being the first to update our linux app after the bug got introduced). Later today, we'll update the ralph and rosetta@home linux apps and they should work.

Since you tracked down the problem, can you please tell us how it will effect all those of us running Rosetta on Linux ?

We already know that those 5.90 tasks will not finish after the specified runtime. Without manual intervention, will these tasks ever end on their own or do I have to go to each and every server and manually abort all the 5.90 tasks ?

I have over 100 cpus running Rosetta on Linux and having to clean up this mess is not something I'm looking forward to. It especially upsets me that the lack of testing on Ralph caused the problem to appear in Rosetta. This was clearly avoidable!

Update: we've tracked down the problem -- its an issue with the BOINC-provided API (I guess we happened to be unlucky in being the first to update our linux app after the bug got introduced). Later today, we'll update the ralph and rosetta@home linux apps and they should work.

All linux users -- thanks for posting! Its quite interesting, in the past, we've seen issues that were Windows-specific, then Mac-specific, but typically linux has been robust (especially since the app doesn't have graphics).

We're looking into the current Rosetta@home/linux issue (I think the cpu time call must be messed up in the latest boinc api), but it may take a few days to track it down. In the meanwhile, please feel free to switch to another app. Apologies... there aren't that many linux users on RALPH -- if you're interested in helping out, we'd be grateful if some more linux clients attached to ralph at least part time.

All linux users -- thanks for posting! Its quite interesting, in the past, we've seen issues that were Windows-specific, then Mac-specific, but typically linux has been robust (especially since the app doesn't have graphics).

We're looking into the current Rosetta@home/linux issue (I think the cpu time call must be messed up in the latest boinc api), but it may take a few days to track it down. In the meanwhile, please feel free to switch to another app. Apologies... there aren't that many linux users on RALPH -- if you're interested in helping out, we'd be grateful if some more linux clients attached to ralph at least part time.

I'm seeing the exact same thing with my AMD64 2800 and my AMD64 X2 4800 as well. I let them work on the tasks for 15 min and still only have --- as a cpu time. Not even 00:00:00. Although I did see the zeros on a couple of the ones from the 6000. Also, after suspending the already running 5.89 tasks both of them changed to "computation error". The 4800 is the only one that produced the "computation error" after suspension. Looks like I'll be windows only after these 5.89's run dry.

NOTE: 5.90 does run on my AMD64 3700 and using windows.

Hmmm, After 15 min and before I could abort the ones on my 4800 one of them switched to 19.864% done, but still shows --- as cpu time.

So are we to assume that there are WU's coming that will have lower virtual memory requirements? The memory hogs are getting tired.

I don't have any advanced knowledge of future Rosetta releases. But my experience with the project tells me they are working on such modications to the program, and so yes, I would assume both that other WUs will require less memory, and that future releases will improve the memory footprint.

It may be helpful if folks would post the WU name and their observations of memory usage. That will provide something concrete to compare against when a new release comes out.

I just got this one it's a resend, the user that had it first had lots

of problems with it. Do you want me to let it run or abort?

It's a BOINC_SYMM_FOLD_AND_DOCK_RELAX-1uis_-crystal_foldanddock.

boinc.bakerlab.org/rosetta/workunit.php?wuid=111015584

Pete.

There is something seriously wrong with the application. It's not a virtual memory hog it's a complete memory hog. I don't have virtual memory, have 2GiB of physical memory. Rosetta now uses 800MB of that for one wu. With the 600MB normally used this is not enough to run two or sometimes even one. I am aborting all version 5.85 tasks until they are disabled.

All Rosetta units are 5.85 now, so please don't abort hundreds of units over and over. Just suspend the project.

I'm sure you've heard this before but. Rossettia version 5.85 is a virtual memory hog. I hope you can find soome ways to fix this problem.

Thank

1di2__LOGREG_ABRELAX_PILOT_ALL_FREQ_SAVE_ALL_OUT-1di2_-_BARCODE__2284_1395

1i8f__BOINC_SYMM_FOLD_AND_DOCK_RELAX-1i8f_-crystal_foldanddock__2257_33840

1igu__BOINC_SYMM_FOLD_AND_DOCK_RELAX-1igu_-crystal_foldanddock__2257_33840