BOINC 6.6.20 released for Windows, Windows x64, and MacOS X

Rom Walton wrote:

Howdy Folks,

We are pleased to announce the first of the 6.6 clients to be ready for
public consumption.

This release includes:

1. A new CPU/GPU scheduler.

2. An improved work-fetch policy.

3. Improved communication handling between the manager and client
software.

4. Consolidation between the grid based advanced view and the list based advanced view for accessibility improvements.

Future 6.6 releases will include the updated localization files that the localizers have been hard at work on.

We would like to thank all the testers for their hard work over the last few months, without your help we would not have had as stable a client as we have now.

----- Rom

---

i don't know that if it is just my vista computer or not but seems to not be getting anymore work. i had to manually detach and reattach to projects to get new work since the upgrade. now seems to not be asking for any new work. well sort of. what exactly was changed if the fetch system????? I mean, maybe it's not getting new work from several projects due to the fact that i have 3 cpdn and a astro needing time to work????

i've even installed version 6.6.21 but no sign of it doing stuff normally. I'm going to switchback to 6.4.7 until this is fixed..... Great.... Now, it gives me a little more info as why it's not getting new task under 4.7

4/10/2009 4:33:11 PM|climateprediction.net|Restarting task hadam3p_m6kz_1984_2_006040725_1 using hadam3p version 606
4/10/2009 4:33:11 PM|uFluids|Restarting task rtube3_0.1_0_16000_31_65_0_0_3 using evolver version 410
4/10/2009 4:33:11 PM|climateprediction.net|Restarting task hadam3p_m6xl_1986_2_006041179_4 using hadam3p version 606
4/10/2009 4:33:11 PM|SETI@home|Restarting task 10fe09ab.15524.24612.11.8.206_0 using setiathome_enhanced version 608
4/10/2009 4:33:24 PM|rosetta@home|Sending scheduler request: Requested by user. Requesting 0 seconds of work, reporting 0 completed tasks
4/10/2009 4:33:29 PM|rosetta@home|Scheduler request completed: got 0 new tasks
4/10/2009 4:33:34 PM|vtu@home|Sending scheduler request: Requested by user. Requesting 0 seconds of work, reporting 0 completed tasks
4/10/2009 4:33:39 PM|vtu@home|Scheduler request completed: got 0 new tasks
4/10/2009 4:33:45 PM|Docking@Home|Sending scheduler request: Requested by user. Requesting 0 seconds of work, reporting 0 completed tasks
4/10/2009 4:33:50 PM|Docking@Home|Scheduler request completed: got 0 new tasks
4/10/2009 4:33:55 PM|Einstein@Home|Sending scheduler request: Requested by user. Requesting 0 seconds of work, reporting 0 completed tasks
4/10/2009 4:34:00 PM|Einstein@Home|Scheduler request completed: got 0 new tasks
4/10/2009 4:34:05 PM|Milkyway@home|Sending scheduler request: Requested by user. Requesting 0 seconds of work, reporting 0 completed tasks
4/10/2009 4:34:10 PM|Milkyway@home|Scheduler request completed: got 0 new tasks
4/10/2009 4:34:15 PM|uFluids|Sending scheduler request: Requested by user. Requesting 0 seconds of work, reporting 0 completed tasks
4/10/2009 4:34:20 PM|uFluids|Scheduler request completed: got 0 new tasks
4/10/2009 4:34:26 PM|World Community Grid|Sending scheduler request: Requested by user. Requesting 0 seconds of work, reporting 0 completed tasks
4/10/2009 4:34:32 PM|World Community Grid|Scheduler request completed: got 0 new tasks

i've even installed version 6.6.21 but no sign of it doing stuff normally.

What you may perceive as normally under the older BOINC versions has changed in 6.6

This version of BOINC comes with a completely new CPU/GPU scheduler, work fetch module, method of calculating debt and a lot more fixes to the engine.

So in essence, if you see it do things differently than you are used to, it does not necessarily mean things are broken, need to be retested and need to be fixed. Try before you return to an older version. And with try I mean more than 5 hours. How about running it for a week, then say what is broken according to you?

A complete log of changes can be found in the aptly named Change Logs thread.

---

I install 6.6.20 under Vista64U and the boinc manager no longer works. It starts up with a message in the lower left saying "starting client servces" and just hangs there, eventually Windows decides it is "(not responding)".

I can see in Task Manager that all the tasks have started and are running but I cannot see them in the Manager, move between tabs, access the menu bar, do anything at all.

I removed 6.6.20 and reinstalled 6.4.7, which restarted without problems and runs fine.

Now that V6.6.x is finally the "recommended" version, some release notes would be nice. Is somebody working on those?

73.
J. Whalen, N6KTC

---

I requested them yesterday. I suppose everyone's off for Easter.

---

Crash Debug from BOINC 6.6.20

Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\WINDOWS\Minidump\Mini041309-02.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 3) MP (4 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp3_gdr.080814-1236
Machine Name:
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055d720
Debug session time: Mon Apr 13 10:32:23.468 2009 (GMT+1)
System Uptime: 0 days 5:38:46.093
Loading Kernel Symbols
...............................................................
................................................................
.........
Loading User Symbols
Loading unloaded module list
..............
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1000000A, {fffffffc, ff, 1, 805417b5}

Probably caused by : win32k.sys ( win32k!fnHkINLPMSG+89 )

Followup: MachineOwner
---------

1: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: fffffffc, memory referenced
Arg2: 000000ff, IRQL
Arg3: 00000001, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 805417b5, address which referenced memory

Debugging Details:
------------------


WRITE_ADDRESS: fffffffc

CURRENT_IRQL: ff

FAULTING_IP:
nt!KiSystemCallExit2+84
805417b5 897308 mov dword ptr [ebx+8],esi

CUSTOMER_CRASH_COUNT: 2

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: boincmgr.exe

LAST_CONTROL_TRANSFER: from 7c90e440 to 805417b5

STACK_TEXT:
ba267834 7c90e440 badb0d00 ba267d65 e2eb4550 nt!KiSystemCallExit2+0x84
WARNING: Frame IP not in any known module. Following frames may be wrong.
ba2678f0 805bfec2 0000ae18 00000000 ba26792c 0x7c90e440
ba267900 805c023a 0000ae18 00000000 00000000 nt!ObReleaseObjectSecurity+0x1a
ba26792c 8062ebea e3556940 0000ab50 00000000 nt!ObCheckObjectAccess+0xd6
ba2679b0 8053618d ba2679d0 ba2679d4 e3a035f8 nt!CmpDoOpen+0x256
ba267a4c 806e6f63 00000000 ba267af4 806e6106 nt!ExAcquireResourceExclusiveLite+0x67
ba267ac4 80503868 00000000 ba268000 ba268000 hal!HalEndSystemInterrupt+0x57
ba267b48 bf85313a 0000002f ba267b70 00000030 nt!KiSwapThread+0xac
ba267bd0 bf852373 00030000 00000001 ba267d18 win32k!fnHkINLPMSG+0x89
ba267c10 bf83c6a6 004f1cb0 00000000 00000001 win32k!xxxHkCallHook+0x30f
ba267c88 bf83c879 03e7fd28 00000000 00000001 win32k!xxxCallHook2+0x25d
ba267ca4 bf801a76 00000000 00000001 00000002 win32k!xxxCallHook+0x26
ba267cec bf819e0f ba267d18 000025ff 00000000 win32k!xxxRealInternalGetMessage+0x264
ba267d4c 8054162c 0012fdc4 00000000 00000000 win32k!NtUserGetMessage+0x27
ba267d4c 7c90e4f4 0012fdc4 00000000 00000000 nt!KiFastCallEntry+0xfc
0012fda0 00000000 00000000 00000000 00000000 0x7c90e4f4


STACK_COMMAND: kb

FOLLOWUP_IP:
win32k!fnHkINLPMSG+89
bf85313a 8bf0 mov esi,eax

SYMBOL_STACK_INDEX: 8

SYMBOL_NAME: win32k!fnHkINLPMSG+89

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: win32k

IMAGE_NAME: win32k.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 49900fc9

FAILURE_BUCKET_ID: 0xA_win32k!fnHkINLPMSG+89

BUCKET_ID: 0xA_win32k!fnHkINLPMSG+89

Followup: MachineOwner
---------

So is this a BOINC Issue or an XP Issue or both :(

Send the debug file, complete with a description of what you did and what your machine is (Make & model CPU, operating system etc.) to Rom Walton at rwalton AT ssl DOT berkeley DOT edu

---

Thanks

I will do that :)

---

Dunno if this is the right place to post this, but here goes:

I've recently installed BOINC 6.6.20 and now mouseover of the BOINC_tray icon in the system tray causes the taskbar to "lose focus".

My task-bar properties have always been configured to enable auto-hide. And so when mouse-over of the BOINC systray object occurs, the task bar immediately loses focus; the net result is auto-hide takes immediate effect.

That occurs when IE 6.0.2900.5512 SP3 browser has focus.

When the MS IE browser is minimized, the aforementioned characteristic doesn't manifest itself.

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

Quote: "What are we supposed to do with the pirate NOW?"

I think this warning is in its place in this thread as well. It's a warning from the Seti forums, but you can see many of its effects on other projects as well.

Richard Haselgrove wrote:

*** WARNING ***

In the course of testing BOINCs v6.6.14/15/16 for compatibility with optimised applications, Lunatics uncovered the cause of the unexpectedly high number of reports of 'High Priority' running with CUDA/optimised applications. The bug in BOINC has been corrected in v6.6.20 and you should see less 'High Priority' from now on.

BUT: this early 'High Priority' is one of the reasons why large cache requests have very rarely been filled in the past. Once any SETI task (AP, MB, or CUDA) goes into High Priority, no further work will be requested.

Until now.

With BOINC v6.6.20, you are much more likely to get what you ask for. And that may be much more than you are expecting.

In the early days of running BOINC v6.6.20, I strongly advise that you turn down your requested cache size, especially on fast multi-cpu, multi-gpu rigs, to no more than one or two days: then turn it back up gradually, allowing work fetch to complete between each change.

There is a secondary problem, which has only just come to light. In BOINC v6.6.20, CUDA tasks always run in "earliest deadline first" (EDF) mode, whether or not they are also running 'High Priority'. If a new CUDA task is downloaded with an earlier deadline than the currently-running CUDA task, the old one will be preempted and the new one will take its place.

Sometimes BOINC is too impatient in doing this, and starts the new task before the old one has finished tidying up after itself. Result: too much graphics memory is allocated, the new CUDA task reports a malloc error, and runs - very slowly - in CPU fallback mode. So, if your upgrade to v6.6.20 triggers a large cache fetch, monitor the next few CUDA tasks and check they're running at normal speed. If they seem to be running slow, and using 100% CPU according to Task Manager, my advice would be to reboot the computer.

[This seems particularly likely just at the moment - Murphy's Law strikes again - because I'm seeing a wide variation of Angle Range and hence deadline in tasks I've downloaded today. VLAR, VHAR, and everything in between. I find my 512MB CUDA cards gag if they are asked to preempt two tasks at once: there's space for a running task and a preempted task in memory, but a third task pushes them over the edge into the malloc error. David Anderson has said that he will try and re-code this part of BOINC next week, so watch out for references to test versions of BOINC v6.6.22 and above]

---

I just installed Boinc 6.6.20 on Vista, 32 bit machine. The Boinc Manager is not showing me any statistics, except for regular messages. The messages say there are downloads and uploads, but the statistics and transfer tabs show no data.

Has anyone else experienced this and/or figured out what's wrong?

Thanks.

It's also worth considering the possibility that a failed migration didn't ***wipe*** the files, it may just have left them behind in an unexpected place. A thorough search (including hidden files/folders) may retrieve the situation.

I also just installed BOINC 6.6.20 and now I cant get any new work for either WCG or SETI under GPU. All of my completion times are all over 300-500 hours on an Intel Q6600 Quad. The completion times were 5-6 hours before the upgrade. I get the following message. Is there something I need to set?

4/25/2009 11:40:28 PM World Community Grid Sending scheduler request: Requested by user.
4/25/2009 11:40:28 PM World Community Grid Not reporting or requesting tasks
4/25/2009 11:40:33 PM World Community Grid Scheduler request completed: got 0 new tasks

4/25/2009 11:47:36 PM SETI@home Sending scheduler request: Requested by user.
4/25/2009 11:47:36 PM SETI@home Not reporting or requesting tasks
4/25/2009 11:47:41 PM SETI@home Scheduler request completed: got 0 new tasks

Have you read the About item at SETI on Astropulse, and how big it is?
Have you set your SETI prefs so as not to get Astropulse work if you don't want long work units?

Have you read the About item at SETI on Astropulse, and how big it is?
Have you set your SETI prefs so as not to get Astropulse work if you don't want long work units?

I do not care how long the work units I get are, but I doubt that any SETI CUDA WUs should have an estimated competion time of 365 hours on a Q6600. They actually complete in 5 to 6 hours.

Everything was working fine before upgrading to 6.20. I upgraded two other machines to 6.20 with no problems.

All the WUs seem to be comnpleting in a reasonable amount of time but the "to completion" times for all of my waiting WUs, both for SETI and WCG, changed to between 300 and 500 hours. I think these really long to completion times is why nothing is downloading anymore. I had three days of work queued up so I am still processing, but have not downloaded anything since I upgraded.

Why should I be showing such long "to competion" times on all of my wating WUs?

---

I do not care how long the work units I get are, but I doubt that any SETI CUDA WUs should have an estimated competion time of 365 hours on a Q6600. They actually complete in 5 to 6 hours.

SETI CUDA WUs normally have a completion time in minutes - down to about 6 minutes per, under ideal circumstances, on my rigs. Even the really, really horrible ones take no longer than 90 minutes.

But they don't run on a Q6600. They run on a computer which has a Q6600 on the motherboard in my case too, but they run on the nVidia card.

5 to 6 hours sounds plausible, but still slow, for ordinary SETI tasks running on the CPU.

You need to be clear in your own mind whether you are seeing slow computation, or a poor initial estimate of what the computation time will be. If it's just the estimate, it should correct itself over time using BOINC's inbuilt mechanisms such as "Duration Correction Factor".

When you upgraded, did you find that all your accounts, projects, tasks etc. were immediately visible when the new BOINC started, or did you - like a few others - have to start with a clean slate? If you lost work and started again - which shouldn't happen, but sometimes does - then all estimates such as DCF get lost too, and have to be re-estimated from scratch.

I do not care how long the work units I get are, but I doubt that any SETI CUDA WUs should have an estimated competion time of 365 hours on a Q6600.

The long ones are not CUDA tasks but AstroPulse, hence the question of Les Bayliss.

I do not care how long the work units I get are, but I doubt that any SETI CUDA WUs should have an estimated competion time of 365 hours on a Q6600.

The long ones are not CUDA tasks but AstroPulse, hence the question of Les Bayliss.

My seti preferences are set to allow CUDA tasks only, no CPU tasks, right now I have 4 WCG WUs active on each CPU and one SETI WU active on the GPU. If AstoPulse only runs on the CPU then I should not have any of them waiting. The problem is not realated to SETI, as both WCG and SETI are showing completion times greater than 300 hours, but when they run, they usually only take 5 hours. There is something wrong with how BOINC it calculating "to completion" time for all WUs, after I upgraded to 6.6.20. I had upgraded from 6.6.0, whcih had no problems. I made no other changes other than upgrading to 6.6.20, and all of the "to completion" times were recaculated for both SETI and WCG, wrong.

---