BOINC 6.3.17 for windows is available.

I think the funczion of bersion .17 ist like the Version .16.

Here are the changes for 6.3.16

* client: if "leave in memory" pref changes, quit suspended tasks
* manager: fix disk display when talking to pre-6.3 client
* MGR: More thorough validity checking to prevent crashes
* client: restore support for max_ncpus preference. This and max_ncpus_pct can both be specified. If both are specified, we take the min
* LIB: Fix the windows callstack dump routine for Visual Studio 2008
* WINSETUP: Don't allow parent permissions to be inhertied from the parent directory when we setup the data directories permissions
* WINSETUP: Include a fix for the ALLUSERS flag so that based on the user preference, the installation settings are honored
* MGR: Have the SkinManager parse the correct spelling of 'organization'.
* MGR: Add a new tab status to the Simple GUI for when the client has been instructed to delay starting applications via the <delay_start> option in cc_config.xml
* WINSETUP: When the shortcut to BOINC Manager remove the minimize flag, it apparently was causing the small manager window. The '/s' parameter already takes care of minimizing the window
* LIB: The max cpu preferences was named 'max_cpus' and not 'max_ncpus' back in the day
* client: the max percent needs to be based on the max cpu preference not the total number of CPUs if we are actually calculating the min of both of them

Seems to run fine on Vista64.
Let's see how it does after some time and some task switches...
____________

pixelicious.at - my little photoblog

6.3.17 seems ok so far, But I've had little time to observe it. I installed it last night but had other things to do and have only been awake 10 minutes today.

6.3.16 had a display bug which I found within the first hour of testing it. Hence the quick release of 6.3.17 same day as 6.3.16.

There are not many scheduler changes in these over 6.3.15 so they should remain stable, most changes were minor tweeks or cosmetic and some fine tuning on the communication between manager and client and the screen redraw to reduce flicker. That was the cause of phanton lines appearing in task display or lines appearing with wrong status of task in 6.3.15 and 6.3.16, harmless but not desired for a public release. I've done quite a few extensive combinations of tasks, projects and loads in 6.3.15 with no signs of it not keeping the proper number of tasks running.

One thing semi-fixed is the startup of manager, like after exit or a reboot, previously if you started it closed, then opened it from the icon the window size was small, not the size you left it. Now it should remain the size you left it, but the position still drifts. At least it is easier to just move the window a little than have to move and resize each time. They will continue to try to figure out why windows can;t remember the position.

It is probably safe to run this version.

You should really wait for a release memo to appear on the alpha email list before posting a version is out on public message boards. 5 of the last 8 versions were not the best and some had major flaws.

This is more for krunchin Keith

When I start BOINC now, I see

10/24/2008 11:27:15 AM||Unrecognized tag in cc_config.xml: <checkpoint_debug>
10/24/2008 11:27:15 AM||Unrecognized tag in cc_config.xml: <coproc_debug>
10/24/2008 11:27:15 AM||Unrecognized tag in cc_config.xml: <cpu_sched>
10/24/2008 11:27:15 AM||Unrecognized tag in cc_config.xml: <cpu_sched_debug>

Also, I keep getting the dialog box to join a project every time the manager starts up (though this build it was the account manager). I already have it attached to BAM!, so why would it be asking to reattach? I did go through and rejoin the BAM! today and the BOINC manager window auto minimized on me as soon as I clicked finish.

Running on Server 2008 x64, installed the 64bit BOINC to its own directories (d:\Datax64 and d:\progx64)

both went away after restarting BOINC. this time. strange.

Now BOINC is quiting on me a few seconds after launching. The manager will stay open with "connecting to local host". If I leave it own, about a min later, it'll reconnect for about 1 sec, then again loose connection. In the task manager, I see BOINC.exe running only for that one second. I am going back to 6.3.15

15 did the same thing, went back to 14, and it *seems* stable again

This is more for krunchin Keith

When I start BOINC now, I see

10/24/2008 11:27:15 AM||Unrecognized tag in cc_config.xml: <checkpoint_debug>
10/24/2008 11:27:15 AM||Unrecognized tag in cc_config.xml: <coproc_debug>
10/24/2008 11:27:15 AM||Unrecognized tag in cc_config.xml: <cpu_sched>
10/24/2008 11:27:15 AM||Unrecognized tag in cc_config.xml: <cpu_sched_debug>

Also, I keep getting the dialog box to join a project every time the manager starts up (though this build it was the account manager). I already have it attached to BAM!, so why would it be asking to reattach? I did go through and rejoin the BAM! today and the BOINC manager window auto minimized on me as soon as I clicked finish.

Running on Server 2008 x64, installed the 64bit BOINC to its own directories (d:\Datax64 and d:\progx64)

both went away after restarting BOINC. this time. strange.

Now BOINC is quiting on me a few seconds after launching. The manager will stay open with "connecting to local host". If I leave it own, about a min later, it'll reconnect for about 1 sec, then again loose connection. In the task manager, I see BOINC.exe running only for that one second. I am going back to 6.3.15

15 did the same thing, went back to 14, and it *seems* stable again

first, sorry 4 the bad english.
i had a problem with my dualcore-cpu. after upgrading from 6.3.15 > 6.3.17, i had only one cpu in the messagewindow of boinc.
then i have craete the cc_config file, but nothing.
so i have look into the file "global_prefs" and have change the line "<max_cpus>x</max_cpus>" (x= number of cpu´s)manual to 2 cpu´s.
now its all ok...i have my both cpu´s again 4 crunching ;D

I hope that I could help!

the underlying logic of cpu-s changed from ncpus to max_cpus in 6.3.17

this will be used for exacter scheduling in the next versions (according to boinc-dev mailinglist some are already trying with different implementations)

the underlying logic of cpu-s changed from ncpus to max_cpus in 6.3.17

this will be used for exacter scheduling in the next versions (according to boinc-dev mailinglist some are already trying with different implementations)

David 22 Oct 2008
- client: restore support for max_ncpus preference.
This and max_ncpus_pct can both be specified.
If both are specified, we take the min.

It would be really nice in these threads about BOINC clients if posters would specify whether they are talking about Windows or Linux clients. I am using Linux only and have to do a lot of scrolling around to see which platform is being discussed to see if it applies to my setups....Thanks

This is more for krunchin Keith

When I start BOINC now, I see

10/24/2008 11:27:15 AM||Unrecognized tag in cc_config.xml: <checkpoint_debug>
10/24/2008 11:27:15 AM||Unrecognized tag in cc_config.xml: <coproc_debug>
10/24/2008 11:27:15 AM||Unrecognized tag in cc_config.xml: <cpu_sched>
10/24/2008 11:27:15 AM||Unrecognized tag in cc_config.xml: <cpu_sched_debug>

Also, I keep getting the dialog box to join a project every time the manager starts up (though this build it was the account manager). I already have it attached to BAM!, so why would it be asking to reattach? I did go through and rejoin the BAM! today and the BOINC manager window auto minimized on me as soon as I clicked finish.

Running on Server 2008 x64, installed the 64bit BOINC to its own directories (d:\Datax64 and d:\progx64)

both went away after restarting BOINC. this time. strange.

Now BOINC is quiting on me a few seconds after launching. The manager will stay open with "connecting to local host". If I leave it own, about a min later, it'll reconnect for about 1 sec, then again loose connection. In the task manager, I see BOINC.exe running only for that one second. I am going back to 6.3.15

15 did the same thing, went back to 14, and it *seems* stable again

It would be really nice in these threads about BOINC clients if posters would specify whether they are talking about Windows or Linux clients. I am using Linux only and have to do a lot of scrolling around to see which platform is being discussed to see if it applies to my setups....Thanks

cant run this project as a service, so no, its not.

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

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

starting the BOINC manager

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

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.

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.

Yes, I had that with the 6.3.10, too, every time I restarted Windows and BOINC the Attach-Window did come up. I first thought it could be a missed setting during the installation, but it wasn't.
After changing to the 6.3.17 all is fine now.

I had 6.3.17 ask to attach to BAM! every time it restarted... got old real quick. Id see the windows "communicating with BAM!" then it would ask for my account info. I finally resubmitted the account info (even though in the message logs I would see it had already connected)and the message never came back.

cant run this project as a service, so no, its not.

I had 6.3.17 ask to attach to BAM! every time it restarted... got old real quick. Id see the windows "communicating with BAM!" then it would ask for my account info. I finally resubmitted the account info (even though in the message logs I would see it had already connected)and the message never came back.

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?

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.

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.

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

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.

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.

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 [16326].

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?

or should I just remove the line?