I have a work unit that seems to be "almost" stuck at 97% complete. The % complete has been slowly increasing (by about .4%) over the last two hours. I have work units set to complete in 4 hours, and we are going over 6 with this one. It is wuid=74278854

Doug, I'm not sure how much reading you've been doing or how long you've been around these boards, but in a word, the reason why is that other people's machines found these tasks were not as great a hurdle as yours did. The raw computational work for each type of task is slightly different. Always highly concenrated on floating point operations, but slightly different.

Your credit issued is based on the credit claims of all those returning results for the same study before you. For the "short" ones, your machine found they crunched more easily then your BOINC benchmarks predicted and you were granted more credit then you claimed. For the "long" ones, other people's machine found them to crunch more easily then their BOINC benchmarks predicted, and they were granted more then they claimed.

There is also variability with a given protein or RNA being studied from model to model, and noone knows ahead of time what a given random starting point will yield. You've only got two of the shorter tasks left in your history. So it is entirely possible that these were unusually high credit for you.

...yes, looking at the rest of your history, you see that the granted credit of about 32 for 13-14,000 seconds of work is abnormally high compared to the rest of your history. ...on the other hand you have one that was granted almost 42 credits for 13,567 seconds of work as well. Another was granted 26 credits for almost exactly same number of seconds.

All of your "long" tasks were new RNA studies. And Rhiju has improved some of the energy functions being used in the new release which just came out today. And these types of improvements will help make the crunch times per model more consistent and remove much of the variability. These RNA studies are still very new science, so I'm sure there is still much to learn about hunting down the best models efficiently.

Yay! For once, my Rosetta workunit checkpointed and resumed OK--it didn't lose any CPU time this time around!

Workunit: here

Hopefully this is the way they will all be now. :-| Probably not though.

I'm thinking, if we could get some better checkpointing around here, it would be nice. Yes, I know that the WU can only checkpoint at certain points in the model, but for people who don't crunch 24/7 (not to mention having other projects that have to share the part of the day that the computer is on), this can be a bit of a problem, at least for the big "Abinition-relax" and "Symmetric Fold And Dock" workunits that seem to be so common lately. When the model takes up to 3 hours to complete, and the model can't be checkpointed very often throughout, you get a problem. Isn't there a better way to checkpoint, that allows you to do so at any time?

I was thinking of a way it might be done (although it probably won't be feasible, I'll say it anyway, in case it helps): You know how if you have your preferences set to leave apps in memory while preempted, if the workunit just pauses, it can sit there, with the entire workunit loaded into memory? I'm thinking, the Rosetta application can simply save everything it has loaded into memory, to disk, and then when it needs to restore from the checkpoint, it will simply load that back into memory, and restore as if it was restoring from a preempted task left in memory. Would this work at all? If so, then if it could be at all possible to make the application save its contents to disk as described every 5 or 10 minutes, that would be enough to make sure that hours of work are not wasted when a computer needs to be shut down!

Hope this helps--although it probably won't (as I am neither a protein expert or a programmer), but maybe it will. :-)

LohnesinPR, I am seeing some tasks taking 5+ hours per model on a 3Ghz Pemtium 4. Your machine has less memory, so perhaps doesn't get sent this type of task. The difference basically is that the models of many of the current tasks are much larger then they used to be. So the time per model is going up.

The 90% thing is the new estimated runtime. Once you exceed your runtime preference (as configured in your Rosetta preferences) they don't really know what % complete to estimate. So they set it to a point that shows you've got about 10 minutes left and reduce exponentially from there.

The results of your crunching are collected at the end of a model. If you look at the graphic, I'll bet you will see you are still working on model 1 and that the steps are increasing. So, things are progressing (even if the % completed may not have a good way to indicate that).

If the above is indeed the case, please do this once. Let the task run for even longer. Let's say up to 48 hours (on your .5 Ghz CPU). The system is already watching the task for you with it's "watchdog". If the watchdog sees no progress being made, it will end the task for you. But I think you will find that you finally complete that first model and the task reports back normally.

I for one enjoy seeing these huge and complex RNA structures being studied. It shows that Rosetta has come a long way from just a year ago when tasks with just 30-50 amino acids were still "interesting". I hope that once you see that your crunching is indeed working properly you will agree. You will also get much more credit for these long running tasks as well since they take so much longer to complete.

I must emulate the sentiments of my fellow crunching colleagues that have stated the 10 reasons before me.

Would like to add some for myself, I crunch for Rosetta because I believe in this project wholeheartedly. Of the many plethora of distributed computing projects available this I believe is the most important. Therefore I have decided to throw my computing might, limited as it may be :), to this project. May God bless your efforts and the cures be found speedily for the terrible afflictions that plague the world today. Long and prosperous life to you all. May it be blessed.

Antony

Hey Doug....Appreciate your comments...by the way.. noticed that you are using BOINC 5.4.9, there is an issue with McAfee Virus on that platform

I also noticed on the preceeding thread that they are using a core client called 5.5.0 and getting similiar credits to E @ home...

I will have to ask where that core client is for download as I had not heard of it.....

user stats

How do I get you to send me that dog? :-)

As it stands I only can crunch for 2 experiments now.Somehow I meesed-up the O.V. and Boinc crashe several times.Now to start Boinc,I must go to home.
"Conquerer" and hold down CNTL click the run Client go to tools and execute
the shell.Then I have to repeat the same to get the Boinc Manager operational.

As well as I can follow what you're having to do to start it, I have to say I'm not sure what would cause that. How were you starting it before? We're you clicking on run_client or were you opening a shell first and typing it in? What does it do when you try to start it the way you used to - does it give you any messages or does it just not start?

All my Malaria w/u failed,but, Einstein and Rosetta still work and am getting better Credits than ever.I may have to do a Complete install of this O.S. Unless you can Delete all Boinc files and reaaply them????

Your benchmarks look better now, so whatever you did there helped a lot. Your floating point went from 378 to 585, and your integer went from 1001 to 1637. That looks much more inline with what other systems like yours seem to report. And that will be why your credits have went up. They seem to have gone from less than 6 credits for 2 hours to just over 9 credits - that looks like a decent improvement for your cpu.

As for the malaria work units failing, that's one of the few projects I've never joined so I can't offer any suggestions on that one short of letting it download a new malaria executable. The best way to do that is to do a project reset on malaria - don't detach, just do the reset. Or if you prefer you can delete the files in the project folder for malaria in your boinc directory - then it will have to download new ones. If you do the project reset, it will keep your client_state file clean as you go whereas deleting the files will trigger an error in boinc which it will then correct by downloading new ones.