Latest WCG branded/Boinc Software Version Thread

nomad8u said:
I haven't had to try it but have heard it is no problem to "downgrade" to a previous version by doing the same thing. Overall a very flexible install/setup routine...
Click to expand...
I have downgraded multiple versions by just installing the older version over the top of the newer one, multiple times with no problems.
 
I have finished and turned in my Boinc 6.6.0 (Pre-release) Alpha tests and I can report that the few bugs that 6.5.0 had seem to be fixed.
The issue's with the scheduler work appear to have been resolved.
I tested with multiple projects including WCG, GPUGRID and GPU-Seti and can report that I had no problems at all. (I must be doing something wrong):D
Testing took place with Vista 32bit and Vista 64 bit only.

Other Alpha testers have reported good reports including that Windows 7 64 bit works well with this 64 bit client version.

This is still a Alpha Pre-release but I would recommend it to anyone that wanted an upgrade from a previous version.

I report again on this client if I do find any problems that have not materialized as of yet (testing has only been for 2 days so far at the time of this report, but have been extensive)

Boinc 6.6.0 (Pre-release) can be downloaded from: http://boinc.berkeley.edu/dl/?C=M;O=D
 
Boinc 6.6.2 News

While we were near the end of the 6.6 milestone and approaching release, they have decided to take the new work-fetch and CPU/GPU scheduling stuff that has been worked on the last few weeks as part of the 6.6 release.

While this may or may not delay the 6.6 release, it’ll lead to a better overall experience for those using both CPU’s and GPU’s.

Shortly they will be releasing the 6.6.2 client which will include the latest work-fetch and CPU/GPU scheduling changes.
 
Boinc 6.6.2 Development version has been released.
Preliminary test looks good but if you run GPU-Seti watch out that you may get a stray CPU-Seti unit mixed in with your Cuda units.
This is due to the downloading of additional work buffer for Cuda and CPU separately.
The problem is that they have not given the ability to specify a value for each separately under the options.
I will mention this to the developers when I submit my Alpha test report.
Downloads here: http://boinc.berkeley.edu/dl/?C=M;O=D
 
With Seti@Home set to : won’t get new tasks and many work units suspended with all CUDA devices running Seti work units and BOINC has over the full day of quota of Seti@Home CUDA units, when manual update is done Boinc 6.6.2 will get new CUDA Seti@Home work every time a manual update is done.
I have continued with this until I have reached over 300+ units over the 200 quota this system is allowed per day. There seems to be no limit.
 
If you are on Boinc 6.6.2 Development version Windows 32bit and were seeing work-fetch problems (e.g. too many jobs fetched, or "no new tasks" not honored), please try this client:
http://boinc.berkeley.edu/dl/boinc_win_17021.exe

NOTE: this is not a full installer (Rom's offline right now).
It's just the client.
You'll need to move it to your BOINC program directory (where boinc.exe is) and rename it to boinc.exe Then restart BOINC.
 
Boinc 6.6.3 Development version has been released.
Download from here: http://boinc.berkeley.edu/dl/?C=M;O=D
This release has many fixes for work-fetch and CPU/GPU scheduling.
Code: 
[FONT=Calibri][SIZE=3]Change Log:[/SIZE][/FONT]
 
[FONT=Courier New]   - Mac client: fix bug in build script so that curl-7.19.2 actually [/FONT]
[FONT=Courier New]       does build with c-ares 1.6.0.  Fixes #830.  (Checked into [/FONT]
[FONT=Courier New]       boinc_core_release_6_6_2 tag and boinc_core_release_6_6a branch.)[/FONT]
[FONT=Courier New]     - client: fix messages[/FONT]
[FONT=Courier New]     - client: fetch work from non-CPU-intensive projects[/FONT]
[FONT=Courier New]   - client: compile fix, remove spurious message[/FONT]
[FONT=Courier New]   - MGR: Make sure the UI thread doesn't call a GUI RPC[/FONT]
[FONT=Courier New]       that uses the SET_LOCALE class.[/FONT]
[FONT=Courier New]   - MGR: fix compile error.[/FONT]
[FONT=Courier New]   - client: if an app has avg_ncpus < 1, run it at above-idle priority[/FONT]
[FONT=Courier New]       even if it doesn't use a coprocessor.[/FONT]
[FONT=Courier New]   - scheduler: added an "nci" (non CPU intensive) plan class[/FONT]
[FONT=Courier New]       to sched_plan.cpp.  It declares the use of 1% of a CPU.[/FONT]
 
[FONT=Courier New]   The above two changes are intended to allow the QCN app to[/FONT]
[FONT=Courier New]   run at above_idle priority, which it needs in order to do 500Hz polling.[/FONT]
 
[FONT=Courier New]   - API: the std::string version of boinc_resolve_filename()[/FONT]
[FONT=Courier New]       acts the same as the char[] version.[/FONT]
[FONT=Courier New]   - client sandbox: add details in switcher_exec "execv failed" message.[/FONT]
[FONT=Courier New]   - MGR: Work around bug in generic list control GetSelectedItemCount() [/FONT]
[FONT=Courier New]       which caused incorrect update of buttons in Projects tab after [/FONT]
[FONT=Courier New]       detching from a project; remove redundant UpdateSelection() call.[/FONT]
[FONT=Courier New]   - MGR: Remove override of GetSelectedItemCount() introduced yesterday;  [/FONT]
[FONT=Courier New]       instead, call DeleteItem() rather than SetItemCount() when number of [/FONT]
[FONT=Courier New]       rows has been reduced, to allow virtual ListCtrl adjust its list of [/FONT]
[FONT=Courier New]       selected rows (and thus keep its count in sync with reality.)[/FONT]
[FONT=Courier New]   - MGR: Don't use wxT() to describe parameters passed to GUI RPCs.[/FONT]
[FONT=Courier New]   - MGR: In CBOINCClientManager::StartupBOINCCore() allow time for Client[/FONT]
[FONT=Courier New]       to start up, to avoid repeated attempts which put spurious messages[/FONT]
[FONT=Courier New]       "Another instance Another instance of BOINC is running" in [/FONT]
[FONT=Courier New]       stderrdae.txt.[/FONT]
[FONT=Courier New]   - client: simplify message describing scheduler request;[/FONT]
[FONT=Courier New]       to get work request details, use <sched_op_debug>[/FONT]
[FONT=Courier New]   - client: when preempting a process, remove it from memory if:[/FONT]
[FONT=Courier New]       1) it uses a coprocessor[/FONT]
[FONT=Courier New]       2) it has checkpointed since the client started[/FONT]
[FONT=Courier New]       3) it's being preempted because of a user action[/FONT]
[FONT=Courier New]           (suspend job, project, or all processing)[/FONT]
[FONT=Courier New]           or user preference (time of day, computer in use)[/FONT]
[FONT=Courier New]   - client: clear debts when reset project[/FONT]
[FONT=Courier New]   - client: respect work-fetch backoff for non-CPU-intensive projects[/FONT]
[FONT=Courier New]   - client: for non-CPU-intensive project, fetch new job[/FONT]
[FONT=Courier New]       if no currently running jobs[/FONT]
[FONT=Courier New]   - client: skip non-CPU-intensive projects in debt calculations[/FONT]
[FONT=Courier New]   - manager: show resource backoff times correctly[/FONT]
[FONT=Courier New]   - client: if we're doing an RPC (for whatever reason)[/FONT]
[FONT=Courier New]       to a non-CPU-intensive project without a job, ask for one.[/FONT]
[FONT=Courier New]   - client: change the LTD policy so that[/FONT]
[FONT=Courier New]       1) net adjustment for eligible projects is zero;[/FONT]
[FONT=Courier New]       2) max LTD is zero[/FONT]
 
Boinc 6.6.4 beta is available for download.
I haven't began testing it yet but thought I would let you all know it's out.
Download at:
http://boinc.berkeley.edu/dl/?C=M;O=D

Edit: Very good version (GPUGRID works great), just don't run it if you do the SIMAP project - it gives errors (this will be fixed in the next version 6.65)

Code: 
[FONT=Calibri][SIZE=3]Change Log:[/SIZE][/FONT]
[FONT='Courier New']    - MGR: call UpdateSelection() from OnListRender() instead of from [/FONT]
[FONT='Courier New']        RestoreSelections().  Fixes #837.[/FONT]
[FONT='Courier New']    - MGR: Suppress Skin Manager error messages by default; enable them [/FONT]
[FONT='Courier New']        only if the Manager is launched from the command line with an [/FONT]
[FONT='Courier New']        argument -c or --checkskins.[/FONT]
[FONT='Courier New']    - client: if we're making an RPC to a project because of user request,[/FONT]
[FONT='Courier New']        clear the resource backoff times so that we potentially[/FONT]
[FONT='Courier New']        can ask the project for work.[/FONT]
[FONT='Courier New']    - lib: comment out perror()s in connection code.[/FONT]
[FONT='Courier New']    - client: remove the "deadlines_missed" and "overworked"[/FONT]
[FONT='Courier New']        clauses from RSC_WORK_FETCH::choose_project()[/FONT]
[FONT='Courier New']    - client: restore notion of overworked;[/FONT]
[FONT='Courier New']        if a project is overworked for a resource R,[/FONT]
[FONT='Courier New']        don't fetch work for R unless there are idle instances[/FONT]
[FONT='Courier New']    - GUI RPC: the "get all projects" RPC now also returns account managers[/FONT]
[FONT='Courier New']    - GUI RPC: Fix compiler warning (missing return value).[/FONT]
[FONT='Courier New']    - client: if user requests RPC, do it even if project is backed off[/FONT]
[FONT='Courier New']    - manager: show backoff interval correctly[/FONT]
[FONT='Courier New']    - client: update LTD correctly[/FONT]
[FONT='Courier New']    - Work fetch / scheduler:[/FONT]
[FONT='Courier New']        There are two mechanisms to prevent the scheduler from[/FONT]
[FONT='Courier New']        sending jobs that won't finish by their deadline.[/FONT]
[FONT='Courier New']        Simple mechanism:[/FONT]
[FONT='Courier New']            The client sends the interval x for which CPUs are projected[/FONT]
[FONT='Courier New']            to be saturated.[/FONT]
[FONT='Courier New']            Given a job with estimated duration y,[/FONT]
[FONT='Courier New']            the scheduler doesn't send it if x + y exceeds the delay bound.[/FONT]
[FONT='Courier New']            If it does send it, x is incremented by y.[/FONT]
[FONT='Courier New']        Complex mechanism:[/FONT]
[FONT='Courier New']            Client sends workload description.[/FONT]
[FONT='Courier New']            Scheduler does EDF simulation, sees if deadlines are missed.[/FONT]
[FONT='Courier New']            The only project using this AFAIK is BOINC alpha test.[/FONT]
[FONT='Courier New']        Neither of these mechanisms takes coprocessors into account,[/FONT]
[FONT='Courier New']        and as a result jobs could be sent that are doomed to[/FONT]
[FONT='Courier New']        miss their deadline.[/FONT]
[FONT='Courier New']        This checkin adds coprocessor awareness to the Simple mechanism.[/FONT]

[FONT='Courier New']        Changes:[/FONT]
[FONT='Courier New']        Client:[/FONT]
[FONT='Courier New']            compute estimated delay (i.e. time until non-saturation)[/FONT]
[FONT='Courier New']            for coprocessors as well as CPU.[/FONT]
[FONT='Courier New']            Send them in scheduler request as part of coproc descriptor.[/FONT]
[FONT='Courier New']    - client: fixed bug that computed CPU estimated delay incorrectly[/FONT]
[FONT='Courier New']    - client: the work request (req_secs) for a resource is the min[/FONT]
[FONT='Courier New']        of the project's share and the shortfall.[/FONT]
[FONT='Courier New']    - client: computation of # idle CUDA instances was wrong[/FONT]
[FONT='Courier New']    - client: tweak work fetch messages[/FONT]
[FONT='Courier New']    - client: buffer 2000 messages instead of 1000[/FONT]
[FONT='Courier New']    - client: work fetch fixes[/FONT]
[FONT='Courier New']    - client: there was a problem with how the round simulator[/FONT]
[FONT='Courier New']        worked in the presence of coprocessors.[/FONT]
[FONT='Courier New']        The simulator maintained per-project queues of pending jobs.[/FONT]
[FONT='Courier New']        When a job finished (in the simulation) it would get[/FONT]
[FONT='Courier New']        one or more jobs from that project's pending queue.[/FONT]

[FONT='Courier New']        The problem: this could cause "holes" in the scheduling of GPUs,[/FONT]
[FONT='Courier New']        and produce an erroneous nonzero shortfall for GPUs,[/FONT]
[FONT='Courier New']        leading to infinite work fetch.[/FONT]

[FONT='Courier New']        The solution: maintain a separate (per-resource, not per--project)[/FONT]
[FONT='Courier New']        queue of pending coprocessor jobs.[/FONT]
[FONT='Courier New']        When a coprocessor job finishes,[/FONT]
[FONT='Courier New']        start pending jobs from the queue for that resource.[/FONT]

[FONT='Courier New']        Another change: the simulator did strict reservation of coprocessors.[/FONT]
[FONT='Courier New']        If there are 2 instances of CUDA,[/FONT]
[FONT='Courier New']        and a 1-instance job is running in the simulation,[/FONT]
[FONT='Courier New']        it wouldn't start an additional 2-instance job.[/FONT]
[FONT='Courier New']        This also can cause erroneous nonzero shortfalls.[/FONT]

[FONT='Courier New']        So instead, schedule coprocessors like CPUs, i.e. saturate them.[/FONT]
[FONT='Courier New']        This can cause distorted completion time estimates,[/FONT]
[FONT='Courier New']        but it's better than infinite work fetch.[/FONT]
[FONT='Courier New']    - client: code cleanup[/FONT]
 
You must log in or register to reply here.
Back
Top