Others on my team are asking why every thing they start BOINC a window pops up to attach to a project.

Weird, I only had that with 6.3.8, or maybe it was 6.3.10.
6.3.17 runs fine here with Vista 64 SP1. I haven't seen any problems `til now...

What exactly are they doing to get the attach to project wizard pop up?

Same for me, I only had that in 6.3.10. When up grading to 6.3.14, 6.3.15, 6.3.16 and 6.3.17 I never saw it again on 3 windows computers.

When I did have it all I did was hit cancel and the window would go away and client would then load all existing projects and go on like it never asked that.

One of my rig with v6.3.17 doesnt have any work..

178.13
Vistax64

Also I got this messages (lots of them):
25-Oct-2008 18:17:16 [---] Internal error: expected process to be executing

After reboot so far the message didnt came back...

edit: changed my resource share to 100 from .2 - now im getting task.
So the resource share plays some role? I thought no matter what your settings, GPU will always run a task.

One of my rig with v6.3.17 doesnt have any work..

178.13
Vistax64

Also I got this messages (lots of them):
25-Oct-2008 18:17:16 [---] Internal error: expected process to be executing

After reboot so far the message didnt came back...

edit: changed my resource share to 100 from .2 - now im getting task.
So the resource share plays some role? I thought no matter what your settings, GPU will always run a task.

Yes, GPU should always run tasks, but tasks are fetched by a separate process, work fetch. The scheduler can't run tasks if work fetch does not get any for it to run. I'm not sure exactly how resource shares play a role in that.

As for the internal error, I saw that too today, for the first time in any client. it came after I had tried to test the graphics button, not sure if that was the cause, but after a restart of the client I have not seen it again, have not tried graphics since then either.

Suddenly too I am seeing bad behavior in 6.3.17 which was not in the 6.3.15 client, I think a new bug has crept in. A moment ago I brought up manager to find the first PS3GRID CPU<1 running (has been for 5 hours), all looked fine, had two other cpu tasks running too (my max). Now one of those two CPU has quit without me touching anything, another did not start, which is not correct. Also too the CPU<1 is running at low priority and in earlier tests all CPU<1 ran at normal priority. If I now suspend PS3GRID CUDA tasks, my CUDA tasks from test project won't start which didn't happen before. Suddenly I got lots of internal errors logged. something is out of whack in this client. After a restart the CUDA runs at normal priority. I see some debugging needs to be done, but that will have to wait until tomorrow. I've been up for 16 hours already today. I'll also have to inquire about tweeks made in 6.3.17 over 6.3.15 to see if we can narrow this down.

Hi Keith,

I just have set up a cc_config.xml, but BOINC won't recognize it. It only shows missing start tag in cc_config.xml.

The cc_config looks like this one -

<cc_config>
<log_flags>
<checkpoint_debug>1</checkpoint_debug>
<coproc_debug>1</coproc_debug>
<cpu_sched>1</cpu_sched>
<cpu_sched_debug>1</cpu_sched_debug>
</log_flags>
</cc_config>

and is placed in the BOINC Data dir.

Any ideas what's wrong?

[edit] Nevermind... I saved it in UTF-8, now as ANSI it works...

---

pixelicious.at - my little photoblog

Suddenly too I am seeing bad behavior in 6.3.17 which was not in the 6.3.15 client, I think a new bug has crept in. A moment ago I brought up manager to find the first PS3GRID CPU<1 running (has been for 5 hours), all looked fine, had two other cpu tasks running too (my max). Now one of those two CPU has quit without me touching anything, another did not start, which is not correct.

Similar problem with the 6.3.17 (reported in the <1 CPU thread). Went back to 6.3.14, 3 CPU tasks + 2 GPU tasks running for 10 minutes so far (1 CPU went to "Waiting to run" within seconds on 6.3.17). I'll watch this for a while in 6.3.14 to see if it ever goes back again for me (to rule out <1 CPU issue versus 6.3.17 issue).

http://www.gpugrid.net/forum_thread.php?id=453&nowrap=true#3342

Something strange is going on. Made the switch from 6.3.10 to 6.3.17 yesterday and it's running 4 CPU + 1 GPU task, as expected. But my log is spammed with entries like this:

26/10/2008 09:46:55|QMC@HOME|Resuming task three_114_peptidsm-ecp2.13554_0 using Amolqc-preRC1 version 501
26/10/2008 09:48:02|QMC@HOME|Resuming task three_114_peptidsm-ecp2.13554_0 using Amolqc-preRC1 version 501
26/10/2008 09:49:09|QMC@HOME|Resuming task three_114_peptidsm-ecp2.13554_0 using Amolqc-preRC1 version 501
26/10/2008 09:50:14|QMC@HOME|Resuming task three_114_peptidsm-ecp2.13554_0 using Amolqc-preRC1 version 501
26/10/2008 09:51:19|QMC@HOME|Resuming task three_114_peptidsm-ecp2.13554_0 using Amolqc-preRC1 version 501

It's not doing this all the time, but really a lot. I have no idea what this means.

MrS

---

Scanning for our furry friends since Jan 2002

Stefan@home wrote:

From the logs it looked like it has to do with the preemption of tasks, but I'm not a dev, I only report what I see... ;)

Yes, but BOINC didn't stop the tasks. Or if it did it's not reporting it.

MrS

---

Scanning for our furry friends since Jan 2002

Stefan@home wrote:

From the logs it looked like it has to do with the preemption of tasks, but I'm not a dev, I only report what I see... ;)

Yes, but BOINC didn't stop the tasks. Or if it did it's not reporting it.

MrS

Actually I was talking about my logs in the other thread. I'm sorry that I haven't stated that... ;)

Here's what I saw when BOINC switched from 4CPU plus 1 GPU to 3 CPU plus 1 GPU tasks:

26.10.2008 08:55:09||[cpu_sched_debug] CPU efficiency old 0.805795 new 0.805822 wall 40.809601 CPU 35.211000 w 0.999528 e 0.862812
26.10.2008 08:55:09|PS3GRID|Master file download succeeded
26.10.2008 08:55:10|Docking@Home|Finished download of 1m0b_mod0013sc_69336_87792.inp
26.10.2008 08:55:10||[cpu_sched_debug] CPU efficiency old 0.805822 new 0.805823 wall 4.367996 CPU 3.628000 w 0.999949 e 0.830587
26.10.2008 08:55:11||[cpu_sched_debug] Request CPU reschedule: files downloaded
26.10.2008 08:55:11||[cpu_sched_debug] schedule_cpus(): start
26.10.2008 08:55:11||[cpu_sched_debug] CPU efficiency old 0.805823 new 0.805826 wall 4.243202 CPU 3.650000 w 0.999951 e 0.860199
26.10.2008 08:55:11|PS3GRID|[cpu_sched_debug] highest debt: 86400.000000 fH25969-GPUTEST4-9-10-acemd_0
26.10.2008 08:55:11|PS3GRID|[cpu_sched_debug] already reserved coprocessors for fH25969-GPUTEST4-9-10-acemd_0
26.10.2008 08:55:11|PS3GRID|[cpu_sched_debug] scheduling fH25969-GPUTEST4-9-10-acemd_0
26.10.2008 08:55:11|PS3GRID|[cpu_sched_debug] highest debt: 84685.714286 Ms17952-GPUTEST4-7-10-acemd_0
26.10.2008 08:55:11||[cpu_sched_debug] rr_sim: insufficient coproc CUDA (1 + 1 > 1)
26.10.2008 08:55:11|PS3GRID|[cpu_sched_debug] insufficient coprocessors for Ms17952-GPUTEST4-7-10-acemd_0
26.10.2008 08:55:11|PS3GRID|[cpu_sched_debug] highest debt: 84685.714286 md16645-GPUTEST4-2-10-acemd_0
26.10.2008 08:55:11||[cpu_sched_debug] rr_sim: insufficient coproc CUDA (1 + 1 > 1)
26.10.2008 08:55:11|PS3GRID|[cpu_sched_debug] insufficient coprocessors for md16645-GPUTEST4-2-10-acemd_0
26.10.2008 08:55:11|PS3GRID|[cpu_sched_debug] highest debt: 84685.714286 Rzx1100-GPUTEST4-8-10-acemd_0
26.10.2008 08:55:11||[cpu_sched_debug] rr_sim: insufficient coproc CUDA (1 + 1 > 1)
26.10.2008 08:55:11|PS3GRID|[cpu_sched_debug] insufficient coprocessors for Rzx1100-GPUTEST4-8-10-acemd_0
26.10.2008 08:55:11|Docking@Home|[cpu_sched_debug] highest debt: 30.228069 1m0b_mod0013sc_70074_87792_0
26.10.2008 08:55:11|Docking@Home|[cpu_sched_debug] scheduling 1m0b_mod0013sc_70074_87792_0
26.10.2008 08:55:11|Docking@Home|[cpu_sched_debug] highest debt: -312.629074 1m0b_mod0013sc_70553_87792_0
26.10.2008 08:55:11|Docking@Home|[cpu_sched_debug] scheduling 1m0b_mod0013sc_70553_87792_0
26.10.2008 08:55:11|Docking@Home|[cpu_sched_debug] highest debt: -655.486217 1m0b_mod0013sc_67283_87792_0
26.10.2008 08:55:11|Docking@Home|[cpu_sched_debug] scheduling 1m0b_mod0013sc_67283_87792_0
26.10.2008 08:55:11|Docking@Home|[cpu_sched_debug] highest debt: -998.343360 1m0b_mod0013sc_69336_87792_0
26.10.2008 08:55:11|Docking@Home|[cpu_sched_debug] scheduling 1m0b_mod0013sc_69336_87792_0
26.10.2008 08:55:11||[cpu_sched_debug] Request enforce CPU schedule: schedule_cpus
26.10.2008 08:55:11||[cpu_sched_debug] enforce_schedule(): start
26.10.2008 08:55:11|PS3GRID|[cpu_sched_debug] want to run: fH25969-GPUTEST4-9-10-acemd_0
26.10.2008 08:55:11|Docking@Home|[cpu_sched_debug] want to run: 1m0b_mod0013sc_70074_87792_0
26.10.2008 08:55:11|Docking@Home|[cpu_sched_debug] want to run: 1m0b_mod0013sc_70553_87792_0
26.10.2008 08:55:11|Docking@Home|[cpu_sched_debug] want to run: 1m0b_mod0013sc_67283_87792_0
26.10.2008 08:55:11|Docking@Home|[cpu_sched_debug] want to run: 1m0b_mod0013sc_69336_87792_0
26.10.2008 08:55:11|PS3GRID|[cpu_sched_debug] processing fH25969-GPUTEST4-9-10-acemd_0
26.10.2008 08:55:11|Docking@Home|[cpu_sched_debug] processing 1m0b_mod0013sc_70074_87792_0
26.10.2008 08:55:11|Docking@Home|[cpu_sched_debug] didn't preempt wu_102208_154906_2_2_0: tr 4962.414900 tsc 649.491398
26.10.2008 08:55:11|Docking@Home|[cpu_sched_debug] processing 1m0b_mod0013sc_70553_87792_0
26.10.2008 08:55:11|Docking@Home|[cpu_sched_debug] didn't preempt wu_102208_154906_2_2_0: tr 4962.414900 tsc 649.491398
26.10.2008 08:55:11|Docking@Home|[cpu_sched_debug] processing 1m0b_mod0013sc_67283_87792_0
26.10.2008 08:55:11|Docking@Home|[cpu_sched_debug] didn't preempt wu_102208_154906_2_2_0: tr 4962.414900 tsc 649.491398
26.10.2008 08:55:11|Docking@Home|[cpu_sched_debug] processing 1m0b_mod0013sc_69336_87792_0
26.10.2008 08:55:11|Docking@Home|[cpu_sched_debug] didn't preempt wu_102208_154906_2_2_0: tr 4962.414900 tsc 649.491398
26.10.2008 08:55:11||[cpu_sched_debug] finished preempt loop, ncpus_used 3.900000
26.10.2008 08:55:11||[cpu_sched_debug] using 3.900000 out of 4 CPUs
26.10.2008 08:55:11|Einstein@Home|[cpu_sched_debug] h1_0600.55_S5R4__224_S5R4a_1 sched state 2 next 2 task state 1
26.10.2008 08:55:11|PS3GRID|[cpu_sched_debug] fH25969-GPUTEST4-9-10-acemd_0 sched state 2 next 2 task state 1
26.10.2008 08:55:11|Cosmology@Home|[cpu_sched_debug] wu_102208_154906_2_2_0 sched state 2 next 2 task state 1
26.10.2008 08:55:11|Einstein@Home|[cpu_sched_debug] h1_0600.55_S5R4__222_S5R4a_1 sched state 2 next 2 task state 1
26.10.2008 08:55:11|Cosmology@Home|[cpu_sched_debug] wu_102208_154924_0_1_0 sched state 1 next 1 task state 9
26.10.2008 08:55:11||[cpu_sched_debug] enforce_schedule: end

---

pixelicious.at - my little photoblog

Suddenly too I am seeing bad behavior in 6.3.17 which was not in the 6.3.15 client, I think a new bug has crept in. A moment ago I brought up manager to find the first PS3GRID CPU<1 running (has been for 5 hours), all looked fine, had two other cpu tasks running too (my max). Now one of those two CPU has quit without me touching anything, another did not start, which is not correct.

Similar problem with the 6.3.17 (reported in the <1 CPU thread). Went back to 6.3.14, 3 CPU tasks + 2 GPU tasks running for 10 minutes so far (1 CPU went to "Waiting to run" within seconds on 6.3.17). I'll watch this for a while in 6.3.14 to see if it ever goes back again for me (to rule out <1 CPU issue versus 6.3.17 issue).

http://www.gpugrid.net/forum_thread.php?id=453&nowrap=true#3342

I know 6.3.14 has problems, it will not work correctly, sooner or later. You can run 6.3.14 if you want to, but it is not perfect.

6.3.15 was next to perfect, when I tested it, as far as scheduling, it has some screen redraw flaws. There is a Windows only version.

At this time I recommend users to use 6.3.10 for linux and 6.3.10 or 6.3.15 for Windows.

If you have not upgraded to 6.3.17, do not.

Some new bug has been introduced into 6.3.17 when running CPU<1. It is not harmful, only leaves you with wrong amount of tasks runing and shows some kind of internal error. once this happens you can only quit and restart, but it will then happen again.

I know 6.3.14 has problems, it will not work correctly, sooner or later. You can run 6.3.14 if you want to, but it is not perfect.

6.3.15 was next to perfect, when I tested it, as far as scheduling, it has some screen redraw flaws. There is a Windows only version.

At this time I recommend users to use 6.3.10 for linux and 6.3.10 or 6.3.15 for Windows.

I'll try 6.3.15.

*UPDATE* 6.3.15 went back to 4 tasks (2 CPU, 2 GPU) shortly after install. I will try 6.3.10, before again trying 6.3.14 again (which ran fine with 3 CPU and 2 GPU tasks for 12+ hours).

I was going to do some testing today, but I'm so burned out, I gave up early this morning.

It was not running correct number of tasks this morning.

I quit boinc and re-started.

Funny thing is, since then, 8 hours ago, it has worked perfectly. At least every time I walk by and looked. Checking message log does not show that internal error. I'm afraid to touch anything else, all I have done since then is switch tabs a few times, messages and tasks. I have not touched anything else in it.

I think what I will do is wait until tomorrow. When I go to work I will check my two systems there running this version. If they are fowled up and show errors, i'll downgrade one to 6.3.16 and one to 6.3.15. Then see how long they run and if I can reproduce the error in those versions. I'm pretty sure its not in 6.3.15. 6.3.16 I only ran about 4 hours or so before 6.3.17 came out. This should help determine when the bug crawled in and may help find out what it is.

Hi,

I'm running 6.3.17 on Vista 64 with a E6750 and 2 GTX280 in SLI mode.

I only run two projects: SETI and GPUGRID
In task manager, i see the three tasks as planned, 2 SETI at low priority and 1 GPU at normal priority.
The CPU usage, tho, is completely abnormal.

When SETI is enabled, i have 90% of CPU split between the two SETI tasks, the GPUGRID is using 3 to 5% tops and the rest is used by the system. The GPUGRID tasks take forever to finish.

When SETI is suspended, the GPUGRID task suddenly takes 20 to 40% CPU, and progresses much faster.

Is there something i should try to make that better ?
Or just stick to fedora ? ;-)

disable SLI to be able to use both video cards to crunch.

However, this doesn't solve the "starving for CPU time" issue.

You could try the setting "on multiprocessor systems use at most xx cpus" and set it to 1 locally. That should give you 1 SETI and 1 GPU-Grid, which should be fine for your dual core. Otherwise I'd certainly disable SLI to crunch 2 WUs if I were you.. but then I wouldn't have bought such hardware anyway ;)

MrS

---

Scanning for our furry friends since Jan 2002

ok thx

i have this hardware to be able to play @ 2560x1600 with full details ;-)

i tried to changed from SLI to none and then back and i lost my projects >:

i'll try a fresh install and see how things are

anyway, GDF said in another topic that things should evolve in a few days, so i guess another version is coming :)

---

Seems that умкертп is more or less OK, excluding CPU consumpting of 6.48 GPU application (on Windows).
But today I found the following phenomena:

28.10.2008 8:29:54|PS3GRID|Sending scheduler request: To fetch work. Requesting 35166 seconds of work, reporting 0 completed tasks
28.10.2008 8:30:00|PS3GRID|Scheduler request completed: got 0 new tasks
28.10.2008 8:30:00|PS3GRID|Message from server: No work sent
28.10.2008 8:30:00|PS3GRID|Message from server: Full-atom molecular dynamics for Cell processor is not available for your type of computer.
28.10.2008 8:30:00|PS3GRID|Message from server: Full-atom molecular dynamics on Cell processor is not available for your type of computer.

Hmm....

Heads-up for anyone who's Windows 6.3.17 or Linux 6.3.18 client is crashing (upon requesting work from any project): check whether cc_config's sched_op_debug is on.

Fixed in changeset [trac]changeset:16326[/trac].

Peter

thx. Will setting it to 0 worf for the time being? or should I just remove the line?

Will setting it to 0 worf for the time being?

Yes, it should. Just the non-zero value is important for triggering the crash.

or should I just remove the line?

If you do not intend to type it in later...

(Now I do not know anymore, why I've not changed it to 0, but renamed to sched____op_debug - possibly to notice it at a later time? Weird idea :-)

Peter