The Rosetta developers have been repeatedly skeptical about my performance improvement estimates. That is not a surprise. Developers are sensitive about their work and frequently think they know more than they do. I had to explain to many compiler developers why their "really neat improvement" was not going to make the impact they forecast. The application developers are farther away from performance problems than the compiler developers.

Their efforts to "hyper optimize" the binary by pulling functions "inline" is based on running 1 copy on a large, idle machine. The result is "sub optimized" results when running 2 or more WU on a machine that strain a critical resource .. like the instruction cache. I am running 36 copies on a machine and the negative impact of inlining functions is pretty obvious.

I am close to being out of here! I started crunching Rosetta because it would run for weeks without any attention, it sure wasn't because of the way low Boinc credit.

Now I have many stuck jobs, have had to abort plenty of jobs and am running out of patience.

Jim

On about half of the jobs, when I reach around 95% completed progress simply crawls. To completion time stops but percentages increment extremely slowly. I assume the job is progreessing but I don;t know.

That would be normal. Especially if you are still on the first model, and/or have a short preferred runtime specified in your Rosetta preferences.

Since then it has run up more than 37 hours. I propose to let it run another day or so and see what happens.

Looks like your preferred runtime is 3hrs. The watchdog should have killed that task some time ago. You've already exited and restarted BOINC and it did not complete the task, so I suggest you abort it. Sorry.

Also, please join the Linux problems discussion

I guess I would suggest ending BOINC and restarting.

The "excess" processes could be due to BOINC going to a "waiting for memory" state. It then starts up another process and crunches on that until memory again cross above your preference.

I see you have 4 cores and 8GB of memory. Do your BOINC General Preferences allow it to use at least 25% of that? For both idle and while active?

I do not see why my machine would have any trouble getting memory for a BOINC application. I have 8 GBytes RAM and allow 75% of it to BOINC when the machine is busy (whatever that means) and 95% when the machine is not busy. Typically, 75% of the RAM is devoted to the input cache, although that can go down somewhat when I run a postgreSQL database application.

I tried stopping BOINC and everything stopped except for the rosetta programs that kept running. The one with all the time on it was the parent of the other three.

I killed them and restarted BOINC and all seems to be running normally. I assume I lost 30 hours credit for that mess.

I guess I would suggest ending BOINC and restarting.

The "excess" processes could be due to BOINC going to a "waiting for memory" state. It then starts up another process and crunches on that until memory again cross above your preference.

I see you have 4 cores and 8GB of memory. Do your BOINC General Preferences allow it to use at least 25% of that? For both idle and while active?

[quote]
[snip]
The 5.5 CPU scheduler waits for the next checkpoint later than 10 seconds before the check (there is some asynchronous code, and several seconds can disappear if the host is slow and busy) unless there is a task the needs extra CPU time to complete on time. This may suspend a task just a few seconds before it is complete if there is a checkpoint there, but normally a checkpoint will only happen once every few minutes. Problems that had to be dealt with: tasks that run for days without checkpointing (there are projects that do this), projects that lie about how much work is left (one project I remember had tasks that had a 100 hours or so of CPU time after 100% complete was reached on some tasks).

[snip]

Is rosetta@home one of these? This morning, after about 5 hours, the boincmgr indicated that rosetta@home reached 100% complete, yet it has been running about 10 hours since then. And really running, not stalled. I am running 5.8.16 of the BOINC client and boincmgr. rosetta_5.69_i686-pc-linux-gnu is the program itself.
This is a Red Hat Enterprise Linux 5 system with two 3.06 GHz hyperthreaded Xeon processors and 8 GBytes RAM.

$ ps -fu boinc
UID PID PPID C STIME TTY TIME CMD
boinc 2420 4627 86 03:52 ? 15:04:04 rosetta_beta_5.80_i686-pc-linux-gnu xx mcr1 _ -output_silent_gz -silent -increase_cycles 10 -new_centroid_packing -abrelax -output_c
boinc 2421 2420 0 03:52 ? 00:00:00 rosetta_beta_5.80_i686-pc-linux-gnu xx mcr1 _ -output_silent_gz -silent -increase_cycles 10 -new_centroid_packing -abrelax -output_c
boinc 2422 2421 0 03:52 ? 00:00:00 rosetta_beta_5.80_i686-pc-linux-gnu xx mcr1 _ -output_silent_gz -silent -increase_cycles 10 -new_centroid_packing -abrelax -output_c
boinc 2423 2421 0 03:52 ? 00:00:00 rosetta_beta_5.80_i686-pc-linux-gnu xx mcr1 _ -output_silent_gz -silent -increase_cycles 10 -new_centroid_packing -abrelax -output_c
boinc 4627 4625 0 Sep29 ? 00:11:16 /home/boinc/BOINC/boinc

I assume you are asking about the comment I've bolded?

...not to my knowledge. I believe the odd symptoms people are seeing on Linux all relate to tasks which show they are not yet completed, but BOINC has requested that they stop crunching and it has scheduled another task, but the Rosetta thread continues working... working what would otherwise be normally. As in it will finish at a normal time... just that it shouldn't still be running.

[quote]
[snip]
The 5.5 CPU scheduler waits for the next checkpoint later than 10 seconds before the check (there is some asynchronous code, and several seconds can disappear if the host is slow and busy) unless there is a task the needs extra CPU time to complete on time. This may suspend a task just a few seconds before it is complete if there is a checkpoint there, but normally a checkpoint will only happen once every few minutes. Problems that had to be dealt with: tasks that run for days without checkpointing (there are projects that do this), projects that lie about how much work is left (one project I remember had tasks that had a 100 hours or so of CPU time after 100% complete was reached on some tasks).

[snip]

G'day NilsB

Welcome to Rosetta@Home

Rosetta does occasionally have Linux errors (3.52% last time I saw).

You can of course abort them if you see them, but the programme will eventually stop itself. The programme will also send debugging information about work unit that failed, so the Rosetta@Home team can reduce these errors even further.

Hope that helps

Hugo.

Check your preferences, the disk space items in particular.
You should allow Rosetta at least 200 MB of disk space. The client will probably not even use that amount, but it wont download wu's when allowed disk space is below 200MB.