hey guys im getting some wierd time estimation with this, last day i had time done counting up, procent clompeted stalled at 0,0000% and time remaining stoud still at 5,30 hours. but my max time is 2 hours.
to day im having time remaining countig up at the exact same speed as time done. so both are counting up but progressbar is filling.

Mini 1.07 score13_hb__envtest_A_1tig_3299_290_0
CPU time = 03.21.22
Progress = 100%
To completion = ---
Status = WAITING TO RUN

Run started today 12.59.10 UTC. Not reported yet as completed by BOINC Manager.

Should I abort or wait some ?? Have tried to 'Suspend' 'Resume' but task just sits there. AMD 4800 2 Cores, both cores are processing tasks just now.

OK now, have just seen the remedy in Rosetta forum. Task has cleared.

Couple things to report.

I've seen some "Exited with 0 status but no finished file" messages. My network has been flaky lately, so that could account for it. Work seems to pick up and finish normally.

I had noticed a few days ago that an Einstein and a Rosetta Mini task were running together. Both were listed as running, but only the Rosetta task was accruing CPU time. Top confirmed that the E@H task wasn't getting any CPU time. Stopping/starting the daemon got things running properly again and I didn't think anything else of it.

I saw the same thing again this evening. I took some screen shots before and after restarting the daemon.








It's this host which runs Fedora 7. Latest updates were installed Friday evening. BOINC 5.10.21 is installed via rpm and it runs as a system daemon. It's this result.

---

Kathryn :o)
The BOINC FAQ Service
The Unofficial BOINC Wiki
The Trac System
More BOINC information than you can shake a stick of RAM at.

I had noticed a few days ago that an Einstein and a Rosetta Mini task were running together. Both were listed as running, but only the Rosetta task was accruing CPU time. Top confirmed that the E@H task wasn't getting any CPU time. Stopping/starting the daemon got things running properly again and I didn't think anything else of it.

I saw the same thing again this evening. I took some screen shots before and after restarting the daemon.

I've also got one sllepy Rosetta Mini 1.07 task from Rosetta, on Windows Boinc 5.10.41. It was also able to continue after restart and finally validated.

Peter

score13_hb_envtest62_A_1opd__3299_1875_0 is currently Waiting to run with progress 100%. The task files are stil in the slot folder. Deadline is a few days away, so I will see how it goes. Run time so far is 3:10:57. My Target CPU run time is 6 hours.

This is the only RALPH task currently on my system (I have tasks for 6 other projects on board at the moment.)

---

score13_hb_envtest62_A_1opd__3299_1875_0 is currently Waiting to run with progress 100%. The task files are stil in the slot folder. Deadline is a few days away, so I will see how it goes. Run time so far is 3:10:57. My Target CPU run time is 6 hours.

This is the only RALPH task currently on my system (I have tasks for 6 other projects on board at the moment.)

if there are any other projects pause them, and pause the others takst 2, so its got to crunch this one. then it will finish normally.

I had noticed a few days ago that an Einstein and a Rosetta Mini task were running together. Both were listed as running, but only the Rosetta task was accruing CPU time. Top confirmed that the E@H task wasn't getting any CPU time. Stopping/starting the daemon got things running properly again and I didn't think anything else of it.

I saw the same thing again this evening. I took some screen shots before and after restarting the daemon.

Happened again.

It's only happening with Einstein. Other projects are running fine with Rosetta Mini.

---

Kathryn :o)
The BOINC FAQ Service
The Unofficial BOINC Wiki
The Trac System
More BOINC information than you can shake a stick of RAM at.

I had noticed a few days ago that an Einstein and a Rosetta Mini task were running together. Both were listed as running, but only the Rosetta task was accruing CPU time. Top confirmed that the E@H task wasn't getting any CPU time. Stopping/starting the daemon got things running properly again and I didn't think anything else of it.

I saw the same thing again this evening. I took some screen shots before and after restarting the daemon.

Happened again.

It's only happening with Einstein. Other projects are running fine with Rosetta Mini.

Hello Kathryn,
I too have had an Einstein say it was running when it wasn't. Restarting Boinc Manager got all things in order. I am running Fedora Core 3 on the machine it stopped on. Ralph, Rosetta and my other projects were all OK. I run the Power App 4.32, that may be the problem, did not see it before.

Waiting to see if the new 1.08 Ralph WU's give a better credit per WU on Windows than 1.07.
I even aborted one 'mini' on Rosetta due to such poor credit issued, but I have let them run in Ralph to help find the problem.

(One other thing Kathryn, how did you get the screen shot into this forum? I tried for 2 hours off an Windows machine into the Rosetta forum and gave up?)

@Keith T, just wait, it will eventually get done, I had one wait at 100% for nearly 2 days before it finished and validated. It just depends on when the Client switches from one project to another and then your short term debt and long term debt balances come into play, before it starts that project again.

---

I had noticed a few days ago that an Einstein and a Rosetta Mini task were running together. Both were listed as running, but only the Rosetta task was accruing CPU time. Top confirmed that the E@H task wasn't getting any CPU time. Stopping/starting the daemon got things running properly again and I didn't think anything else of it.

I saw the same thing again this evening. I took some screen shots before and after restarting the daemon.

Happened again.

It's only happening with Einstein. Other projects are running fine with Rosetta Mini.

I am in no position (and totally unqualified) to check this out, but if this were to happen on my Mac my first question would be: What is the behavior of the kernel_task process? (See <a href="https://ralph.bakerlab.org//forum_thread.php?id=326&nowrap=true#3338">this message</a>.)

I had noticed a few days ago that an Einstein and a Rosetta Mini task were running together. Both were listed as running, but only the Rosetta task was accruing CPU time. Top confirmed that the E@H task wasn't getting any CPU time. Stopping/starting the daemon got things running properly again and I didn't think anything else of it.

I saw the same thing again this evening. I took some screen shots before and after restarting the daemon.

Happened again.

It's only happening with Einstein. Other projects are running fine with Rosetta Mini.

Hello Kathryn,
I too have had an Einstein say it was running when it wasn't. Restarting Boinc Manager got all things in order. I am running Fedora Core 3 on the machine it stopped on. Ralph, Rosetta and my other projects were all OK. I run the Power App 4.32, that may be the problem, did not see it before.

Waiting to see if the new 1.08 Ralph WU's give a better credit per WU on Windows than 1.07.
I even aborted one 'mini' on Rosetta due to such poor credit issued, but I have let them run in Ralph to help find the problem.

Hmmm... Well, I'll pop over to E@H and report it there too I guess. I had no problems with E@H until I started up Ralph. I've set Ralph to NNT for the moment and we'll see if I run into the problem again. Then I'll reenable work fetch for Ralph and see if I can reproduce the stalling.

(One other thing Kathryn, how did you get the screen shot into this forum? I tried for 2 hours off an Windows machine into the Rosetta forum and gave up?)

Upload it to someplace like imageshack or photobucket and put the resulting url between bbcode image tags. Photobucket will actually generate the bbcode for you so all you have to do is copy/paste.

---

Kathryn :o)
The BOINC FAQ Service
The Unofficial BOINC Wiki
The Trac System
More BOINC information than you can shake a stick of RAM at.

I had noticed a few days ago that an Einstein and a Rosetta Mini task were running together. Both were listed as running, but only the Rosetta task was accruing CPU time. Top confirmed that the E@H task wasn't getting any CPU time. Stopping/starting the daemon got things running properly again and I didn't think anything else of it.

I saw the same thing again this evening. I took some screen shots before and after restarting the daemon.

Happened again.

It's only happening with Einstein. Other projects are running fine with Rosetta Mini.

I am in no position (and totally unqualified) to check this out, but if this were to happen on my Mac my first question would be: What is the behavior of the kernel_task process? (See <a href="https://ralph.bakerlab.org//forum_thread.php?id=326&nowrap=true#3338">this message</a>.)

Can you put that in English for the technically challenged among us (/me points to self)?

---

Kathryn :o)
The BOINC FAQ Service
The Unofficial BOINC Wiki
The Trac System
More BOINC information than you can shake a stick of RAM at.

I had noticed a few days ago that an Einstein and a Rosetta Mini task were running together. Both were listed as running, but only the Rosetta task was accruing CPU time. Top confirmed that the E@H task wasn't getting any CPU time. Stopping/starting the daemon got things running properly again and I didn't think anything else of it.

I saw the same thing again this evening. I took some screen shots before and after restarting the daemon.

Happened again.

It's only happening with Einstein. Other projects are running fine with Rosetta Mini.

I am in no position (and totally unqualified) to check this out, but if this were to happen on my Mac my first question would be: What is the behavior of the kernel_task process? (See <a href="https://ralph.bakerlab.org//forum_thread.php?id=326&nowrap=true#3338">this message</a>.)

Can you put that in English for the technically challenged among us (/me points to self)?

My reaction to the whole thread 326 is, that it contains very confusing combination of posts, especialy these concerning kenel_task process and these from Anonymous. Maybe the only relevant think I'd agree with was what anders_n suggested.

I've also had such sleepy tasks in the past and also few days ago. Not only Rosettas, maybe mostly. No idea whether to blame the application or Boinc client for this. Either the client will forget to really wake up the app, or the app will miss the wakeup, or is somehow stuck internally and really can't wake up? (Although it is still responding to the heartbeat.) Maybe this is then the reason why only restarting the client cures the situation (although restarting the single sleepy application would be enough).

Maybe it could help to debug such cases if the wake-up event from client would need a response from the app and client would log such missing response?

Peter

I am in no position (and totally unqualified) to check this out, but if this were to happen on my Mac my first question would be: What is the behavior of the kernel_task process? (See <a href="https://ralph.bakerlab.org//forum_thread.php?id=326&nowrap=true#3338">this message</a>.)

Can you put that in English for the technically challenged among us (/me points to self)?

My reaction to the whole thread 326 is, that it contains very confusing combination of posts, especialy these concerning kenel_task process and these from Anonymous. Maybe the only relevant think I'd agree with was what anders_n suggested.

In these matters *I* am the technically challenged with 6 hours computer instruction a generation ago. And I am sorry if my posts appear confusing.

However, if I discover a Rosetta process continuously running without (seemingly) using any CPU time I list the active processes on my Mac using the Activities Manager, one item being a Rosetta process using no CPU. The process always at the bottom of the list is "kernel_task", usually occupying around 0.5-2 % CPU time. If it consistently uses 30-40 % I know it is not behaving quite normally. Then I go through the rest of the processes looking for a program using more CPU than appropriate (because it should not be processing anything at the time). I always find such a program, and restarting this program shrinks the CPU usage of kernel_task and normalise the CPU usage of the Rosetta process.

I cannot explain the matter, but at least the method works in my situation.