More problems on Mac O S X 10.4.11

WU's 1376869,1376870,1376871 failed: see below

ERROR: Conformation: fold_tree nres should match conformation nres. conformation nres: 137 fold_tree nres: 156589050
ERROR:: Exit from: src/core/conformation/Conformation.cc line: 224
BOINC:: Error reading and gzipping output datafile: default.out
called boinc_finish

</stderr_txt>

Chu! Long time no "see"! Welcome back.

What's with the little red ball?

Make this thread sticky. Maybe unsticky some others.

Is this memory usage normal?

12/02/2007 02:41|ralph@home|Message from server: Your computer has 313.84MB of memory, and a job requires 476.84MB
12/02/2007 02:41|ralph@home|Message from server: No work sent
12/02/2007 02:41|ralph@home|Message from server: (there was work but your computer doesn't have enough memory)
12/02/2007 02:41|ralph@home|No work from project

This seems to be new, because this host has already crunched some WUs.

cu,
Micha

I just got one of these WUs:
1who__BOINC_ABINITIO_CONTROL2__1749_26_0 using rosetta_beta version 545
the graphic doesn't show the sidechains.

> Just had 4 Work Units fail, all at 1 hour processing time, I am expecting the other 2 to fail as well.
All the work units got 'stuck' and the Watchdog says it ended the run, but this is not the case.
All 4 work units on the Boinc Manager said that they were still running with NO CPU usage but still using up to 308 MB of RAM for each WU. All 4 got to 1 hour (my preferences are for 6 hours) and then said they were 100% complete but the WU did not release the CPU to go to another task.

http//ralph.bakerlab.org/result.php?resultid=420621
http//ralph.bakerlab.org/result.php?resultid=420709
http//ralph.bakerlab.org/result.php?resultid=420761
http//ralph.bakerlab.org/result.php?resultid=420767

Thanks

I have 2 computers running Fedora core 6 that seem to get hung up on certain WUs. It's happening with both ralph 5.45 & rosetta 5.45.

The first one is a Pent D 2.8 with 1Gb RAM and the 2nd is an old laptop with a Pent 4M 1.8 with 1Gb RAM.

They both seem to hang on workunits. The WU will get around 1/3 complete and then the CPU in boincview will drop to 0. I've left them running overnight to see if they become unstuck but they never do.

WUs:
http://ralph.bakerlab.org/workunit.php?wuid=365447
http://boinc.bakerlab.org/rosetta/workunit.php?wuid=53704537

Anybody have any ideas?

-J

It isn't possible to test this update on my Mac as there is no work units. I did get 2 work units on one day, but they ran and I didn't notice them, so I couldn't turn on the graphics.

The error message you got is certainly one of the symtoms related to graphics, but definitely not limited to that. May I ask if you have experienced any stability issue with your machine in general?

Hi Chu. Apologies for the long post.

No, I've never had any stability issue with my machine for any applications I run on it, with the sole exception that it doesn't like running the BOINC manager at the same time as I'm ripping DVDs. Other than that, it's rock solid. It's fairly well overclocked -I'm running a Core2Duo E6700 at 3.46 GHz, and my PC6400-rated RAM is actually running as PC8200 - but it's tested completely stable and several months of running both cores at 100% capacity 24/7 has never generated a single error for any BOINC application WU except Rosetta. Rosetta, though, became very touchy about running. It would inevitably fail a WU that was pre-empted and swapped out to allow something else to run. I had to leave it runing all the time on one core.

We certainly do not want to lose users because of application stability and that is why we are trying to work on improving it. Maybe you can check whether this is improved in 5.45 and if the failure rate goes down significantly, you may considering attaching back to Rosetta@Home.

I was quite puzzled and a bit disturbed at how the failure rate on Rosetta got more and more pronounced over time without any change to my machine's configuration or any other evidence of instability. I kept going for as long as possible because I liked crunching Rosetta and I'd accumulated a very respectable number of WUs. But the failure rate was becoming alarming, and on the 15th-16th January this year some 75-80% of all WUs aborted prematurely. That's when I regretfully had to call a halt. I joined RALPH to see whether the newer versions were more stable with an eye to going back to Rosetta when they're implemented. It's hard to tell, since the fairly irregular availability of work means I don't have a large WU base to draw conclusions from, but both 5.45 and 5.44 before it seem more stable than 5.43 on my machine; for one thing, they can both be swapped in and out to allow other BOINC applications to run without causing problems.

Out of curiosity, since the beta versions seemed more stable, I allowed my BOINC manager to download some new Rosetta workunits under 5.43 on Jan 27th. Sure enough, the first three it tried to run all failed with access violations, here, here and here. The fourth WU succeeded. By that stage, though, I'd had enough again and shut it down.

I have no idea why this is happening, and the 10% failure rate you mention would have been, if anything, an overestimate of the situation during the first few months I was crunching. The problems really seem to stem from the introduction of 5.43; which is puzzling since I don't use the graphics. I'll certainly try Rosetta again when 5.43 is upgraded, but I'd be a lot happier if I knew what was going wrong.

1 more stck Wu on my MAC.

http://ralph.bakerlab.org/result.php?resultid=406892

I will set the target time 4 H to se if it problem dissapears.

Anders n

Failed WU here.

Same type of error that forced me to stop crunching Rosetta altogether after decreasing stability for ver 5.43 resulted in around 75% of WUs aborting prematurely. Never had this problem at all with any WUs from other BOINC applications I run (World Community Grid/Malaria Control) and very rare with Rosetta before version 5.43. Had one instance of the same with version 5.44 here. Also, along with others, saw three odd, unrelated WU failures with ver 5.44 just before 5.45 was introduced here, here and here. I know these latter aren't ver 5.45, but for sake of completelness I thought it was worth mentioning.

I don't use graphics, at all. All these errors, and almost all of the constant errors being thrown up by Rosetta ver 5.43, occurred while the application was running in the background and the machine was otherwise idle.

Ya my TFlops comment was optimisitically looking forward to the new code rolling out to Rosetta and less users there having problems or confusion, or leaving due to failures.

I think just do what you're doing, keep small amounts of work coming at various times of day (think dial-up, each day after work). But I just wanted to point out that this test has enough special circumstances around it that it needs more time then most you've done before here on Ralph.

Speaking of TFlops, were you able to devise thread safety without too much of a performance impact? I've always been curious how many conformations would be showing if the graphic actually showed each and every one of them.

I picked up two DOC WUs last night on the PC that I was trying (and having problems with) previously, running 24hr time pref. so they're 6.5hrs in without any graphics enabled. Then I'll be using my PC most of today and have suspended Rosetta and enabled the ss for tonight.

...2 DOC WUs, one using 204MB the other using 177MB. So, I'll ask again, is there a simple way we can tell that a given WU was designed for high memory systems?

I just successfully completed one WU.

Opened the graphics window and played around rotating the protein.

Using BOINC 5.8.6a. P4 2.8, 512 of RAM, XP Pro.

Yippie!! Project TFlops here we come!

Do you plan to do several batches of Ralph testing? People need time to suspend Rosetta so they can enable the screensaver to test the Ralph tasks, and then time to catch some tasks available on the server etc. etc.

1,000 tasks, twice a day for a few days?

Keep in mind, most users now do not use the screensaver. And most Ralph users also run Rosetta, so we're going to have to do a little jockeying around to do some good tests.

> Had another Boinc hiccup that somehow created a new host for no reason (created a new host on 3 other projects as well) and it is using the new host not the old one.
I went into the computer and selected "Merge Hosts" but the system tells me there are no hosts to merge. Of the 4 projects I got the same computer duplicated 2 of them (QMC and Einstein) allowed me to merge the computers back into one machine. Docking and Ralph have not allowed me to merge them.

Host 3204 is my host
Host 5474 is the new host that got created.
They both have the same specs but I can't merge them.

I would like the credit to all be on the one machine, Boinc shows the computer to be AuthenticAMD Dual Core AMD Opteron(tm) Processor 2.

Thanks and hope to hear from you soon.

This is my post from the 21/11/06, I would very much like to hear from the project staff.

I have resolved the problem I mentioned in this post on the 7th October as I was able to delete the host seeing as it had no credit (AMD 4800+ host).

However I am still unable to merge my AMD Opteron 275 (shown in Boinc as AuthenticAMD Dual Core AMD Opteron(tm) Processor 2).
I have not heard from the project staff and was wondering if you'd had a chance to see why I am unable to merge these two hosts (3204 and 5474).
They both have credit so I can't just delete one.

Hoping to hear from you soon.

Can you help me Ralph@home project team? I would like these two hosts merged but it does not work from my account.
Still hoping to hear from you soon.

With last WU on Linux box I'm getting this message right after WU starts:

ralph@home 21.1.07 11:09:15 Task 1c9oA_BOINC_ABRELAX_NEWRELAXFLAGS_frags83__1640_3_0 exited with zero status but no 'finished' file
ralph@home 21.1.07 14:50:47 If this happens repeatedly you may need to reset the project.

Resseting project doesn't help.
Any idea?