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.

The mechanics have not changed, but maybe the permissions. Did BM say right hand bottom it was connected to the core client with the version number?

---

Coelum Non Animum Mutant, Qui Trans Mare Currunt

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?"

The all new and improved 6.6.20 scheduler pushed out and all getting the notification in their log (except a certain group) of the latest "good for public consumption". Well, reported this odd pre-empting about before 10-15 point releases ago and had not seen it since few point releases before 6.6.17, but hay 6.6.23 and we're back on zero progress, for those that don't have LAIM (would the english pronounce this as lame too?). A log sample

14/04/2009 17.00.33 PrimeGrid [cpu_sched] Resuming psp_sr2sieve_22113979_0
14/04/2009 17.00.33 PrimeGrid Resuming task psp_sr2sieve_22113979_0 using psp_sr2sieve version 111
14/04/2009 17.00.46 PrimeGrid [cpu_sched] Preempting psp_sr2sieve_22113979_0 (left in memory)
14/04/2009 17.00.46 QMC@HOME [cpu_sched] Resuming two_2am_stackexp-ecp2-DZ.8493_1
14/04/2009 17.00.46 QMC@HOME Resuming task two_2am_stackexp-ecp2-DZ.8493_1 using Amolqc-preRC1exp version 501
14/04/2009 17.01.02 QMC@HOME [cpu_sched] Preempting two_2am_stackexp-ecp2-DZ.8493_1 (left in memory)
14/04/2009 17.01.02 PrimeGrid [cpu_sched] Resuming psp_sr2sieve_22113979_0
14/04/2009 17.01.02 PrimeGrid Resuming task psp_sr2sieve_22113979_0 using psp_sr2sieve version 111
14/04/2009 17.01.04 PrimeGrid [cpu_sched] Preempting psp_sr2sieve_22113979_0 (left in memory)
14/04/2009 17.01.04 QMC@HOME [cpu_sched] Resuming two_2am_stackexp-ecp2-DZ.8493_1
14/04/2009 17.01.04 QMC@HOME Resuming task two_2am_stackexp-ecp2-DZ.8493_1 using Amolqc-preRC1exp version 501
14/04/2009 17.01.13 QMC@HOME [cpu_sched] Preempting two_2am_stackexp-ecp2-DZ.8493_1 (left in memory)
14/04/2009 17.01.13 PrimeGrid [cpu_sched] Resuming psp_sr2sieve_22113979_0
14/04/2009 17.01.13 PrimeGrid Resuming task psp_sr2sieve_22113979_0 using psp_sr2sieve version 111
14/04/2009 17.01.22 PrimeGrid [cpu_sched] Preempting psp_sr2sieve_22113979_0 (left in memory)
14/04/2009 17.01.22 rosetta@home [cpu_sched] Resuming lr5_E_no_rama_04_intra_rep_rlbd_1ubi_SAVE_ALL_OUT_10755_841_0
14/04/2009 17.01.22 rosetta@home Resuming task lr5_E_no_rama_04_intra_rep_rlbd_1ubi_SAVE_ALL_OUT_10755_841_0 using minirosetta version 154
14/04/2009 17.01.26 rosetta@home [cpu_sched] Preempting lr5_E_no_rama_04_intra_rep_rlbd_1ubi_SAVE_ALL_OUT_10755_841_0 (left in memory)
14/04/2009 17.01.26 QMC@HOME [cpu_sched] Resuming two_2am_stackexp-ecp2-DZ.8493_1
14/04/2009 17.01.26 QMC@HOME Resuming task two_2am_stackexp-ecp2-DZ.8493_1 using Amolqc-preRC1exp version 501
14/04/2009 17.01.39 QMC@HOME [cpu_sched] Preempting two_2am_stackexp-ecp2-DZ.8493_1 (left in memory)
14/04/2009 17.01.39 PrimeGrid [cpu_sched] Resuming psp_sr2sieve_22113979_0
14/04/2009 17.01.39 PrimeGrid Resuming task psp_sr2sieve_22113979_0 using psp_sr2sieve version 111
14/04/2009 17.01.50 PrimeGrid [cpu_sched] Preempting psp_sr2sieve_22113979_0 (left in memory)
14/04/2009 17.01.50 rosetta@home [cpu_sched] Resuming lr5_E_no_rama_04_intra_rep_rlbd_1ubi_SAVE_ALL_OUT_10755_841_0
14/04/2009 17.01.50 rosetta@home Resuming task lr5_E_no_rama_04_intra_rep_rlbd_1ubi_SAVE_ALL_OUT_10755_841_0 using minirosetta version 154
14/04/2009 17.02.06 rosetta@home [cpu_sched] Preempting lr5_E_no_rama_04_intra_rep_rlbd_1ubi_SAVE_ALL_OUT_10755_841_0 (left in memory)
14/04/2009 17.02.06 QMC@HOME [cpu_sched] Resuming two_2am_stackexp-ecp2-DZ.8493_1
14/04/2009 17.02.06 QMC@HOME Resuming task two_2am_stackexp-ecp2-DZ.8493_1 using Amolqc-preRC1exp version 501
14/04/2009 17.02.17 World Community Grid [checkpoint_debug] result HFCC_t1_00273561_TrkB_0002_0 checkpointed
14/04/2009 17.02.33 QMC@HOME [cpu_sched] Preempting two_2am_stackexp-ecp2-DZ.8493_1 (left in memory)
14/04/2009 17.02.33 PrimeGrid [cpu_sched] Resuming psp_sr2sieve_22113979_0
14/04/2009 17.02.33 PrimeGrid Resuming task psp_sr2sieve_22113979_0 using psp_sr2sieve version 111
14/04/2009 17.02.47 PrimeGrid [cpu_sched] Preempting psp_sr2sieve_22113979_0 (left in memory)
14/04/2009 17.02.47 QMC@HOME [cpu_sched] Resuming two_2am_stackexp-ecp2-DZ.8493_1
14/04/2009 17.02.47 QMC@HOME Resuming task two_2am_stackexp-ecp2-DZ.8493_1 using Amolqc-preRC1exp version 501

Any reason why these are battling it out on Vista 32, quad? LAIM is on so every second does actually count. ;>)

---

Coelum Non Animum Mutant, Qui Trans Mare Currunt

Something else. Checkpointing. If set to 5 minutes on a quad, how often is this to register and allow a checkpoint write, provided the sciences ask for permission. So happens that under 6.6.23 with 5 minutes ät most" and 2 applications known to write one every minute or several minutes (DDDT & RICE), one is only being recorded every 15 minutes or more.

14/04/2009 17.44.55 World Community Grid [checkpoint_debug] result HFCC_t1_00279513_TrkB_0002_0 checkpointed
14/04/2009 17.50.04 World Community Grid [checkpoint_debug] result dddt1002p0864_100306_0 checkpointed
14/04/2009 17.54.02 World Community Grid [checkpoint_debug] result R00270_b00f5fa921c9e1c31699fcd04438d3aa_01_000_6 checkpointed
14/04/2009 18.00.32 World Community Grid [checkpoint_debug] result E000490_575B_002a0s009_1 checkpointed
14/04/2009 18.13.39 World Community Grid [checkpoint_debug] result dddt1002p0864_100306_0 checkpointed
14/04/2009 18.14.34 World Community Grid [checkpoint_debug] result R00270_b00f5fa921c9e1c31699fcd04438d3aa_01_000_6 checkpointed
14/04/2009 18.14.52 World Community Grid [checkpoint_debug] result HFCC_t1_00279513_TrkB_0002_0 checkpointed
14/04/2009 18.34.34 World Community Grid [checkpoint_debug] result E000490_575B_002a0s009_1 checkpointed
14/04/2009 18.34.34 World Community Grid [checkpoint_debug] result R00270_b00f5fa921c9e1c31699fcd04438d3aa_01_000_6 checkpointed
14/04/2009 18.34.53 World Community Grid [checkpoint_debug] result HFCC_t1_00279513_TrkB_0002_0 checkpointed
14/04/2009 18.36.03 World Community Grid [checkpoint_debug] result dddt1002p0864_100306_0 checkpointed

---

Coelum Non Animum Mutant, Qui Trans Mare Currunt

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.

?

1. The Transfer tab only shows anything during transmission of tasks and result files.

2. If you had statistics before on that machine and not now, you must have lost the previous files. Upgrading has always retained them for me on Vista, to include migrating... until I came across one of the earlier, 6.6.10 or so releases, which thoroughly wiped all and everything, no migration, utter clean slate. If that happened to you too, takes 30 days to populate that stats tab again. That said for longer I've had in the cc_config.xml the <options> line <save_stats_days>91</save_stats_days> so 3 months shows.

---

Coelum Non Animum Mutant, Qui Trans Mare Currunt

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.

Something else. Checkpointing. If set to 5 minutes on a quad, how often is this to register and allow a checkpoint write, provided the sciences ask for permission. So happens that under 6.6.23 with 5 minutes ät most" and 2 applications known to write one every minute or several minutes (DDDT & RICE), one is only being recorded every 15 minutes or more.

14/04/2009 17.44.55 World Community Grid [checkpoint_debug] result HFCC_t1_00279513_TrkB_0002_0 checkpointed
14/04/2009 17.50.04 World Community Grid [checkpoint_debug] result dddt1002p0864_100306_0 checkpointed
14/04/2009 17.54.02 World Community Grid [checkpoint_debug] result R00270_b00f5fa921c9e1c31699fcd04438d3aa_01_000_6 checkpointed
14/04/2009 18.00.32 World Community Grid [checkpoint_debug] result E000490_575B_002a0s009_1 checkpointed
14/04/2009 18.13.39 World Community Grid [checkpoint_debug] result dddt1002p0864_100306_0 checkpointed
14/04/2009 18.14.34 World Community Grid [checkpoint_debug] result R00270_b00f5fa921c9e1c31699fcd04438d3aa_01_000_6 checkpointed
14/04/2009 18.14.52 World Community Grid [checkpoint_debug] result HFCC_t1_00279513_TrkB_0002_0 checkpointed
14/04/2009 18.34.34 World Community Grid [checkpoint_debug] result E000490_575B_002a0s009_1 checkpointed
14/04/2009 18.34.34 World Community Grid [checkpoint_debug] result R00270_b00f5fa921c9e1c31699fcd04438d3aa_01_000_6 checkpointed
14/04/2009 18.34.53 World Community Grid [checkpoint_debug] result HFCC_t1_00279513_TrkB_0002_0 checkpointed
14/04/2009 18.36.03 World Community Grid [checkpoint_debug] result dddt1002p0864_100306_0 checkpointed

Anyone alive? Progressed to 6.6.24 which as the changelog indicates now logs checkpoints in the slots nd less in the client_state.xml. Still seeing not 1 in 5 minutes on projects that have every minute writing, but only one every 20 minutes on a quad. Anything up as to why that changed? Bug?

a 2009/04/24 11:48:25 World Community Grid [checkpoint_debug] result R00272_8fad0eb181248669d23fa71606c8fe4e_03_011_0 checkpointed
b 2009/04/24 11:51:07 World Community Grid [checkpoint_debug] result dddt1102e0279_100386_0 checkpointed
c 2009/04/24 11:56:48 World Community Grid [checkpoint_debug] result E000526_357A_00417q00z_0 checkpointed
d 2009/04/24 12:09:04 World Community Grid [checkpoint_debug] result E000526_375A_00417s00b_1 checkpointed
a 2009/04/24 12:12:08 World Community Grid [checkpoint_debug] result R00272_8fad0eb181248669d23fa71606c8fe4e_03_011_0 checkpointed
b 2009/04/24 12:13:33 World Community Grid [checkpoint_debug] result dddt1102e0279_100386_0 checkpointed
c 2009/04/24 12:24:21 World Community Grid [checkpoint_debug] result E000526_357A_00417q00z_0 checkpointed
d 2009/04/24 12:34:55 World Community Grid [checkpoint_debug] result E000526_375A_00417s00b_1 checkpointed
b 2009/04/24 12:36:12 World Community Grid [checkpoint_debug] result dddt1102e0279_100386_0 checkpointed
a 2009/04/24 12:36:45 World Community Grid [checkpoint_debug] result R00272_8fad0eb181248669d23fa71606c8fe4e_03_011_0 checkpointed
c 2009/04/24 12:46:04 World Community Grid [checkpoint_debug] result E000526_357A_00417q00z_0 checkpointed
b 2009/04/24 12:56:28 World Community Grid [checkpoint_debug] result dddt1102e0279_100386_0 checkpointed
a 2009/04/24 12:57:31 World Community Grid [checkpoint_debug] result R00272_8fad0eb181248669d23fa71606c8fe4e_03_011_0 checkpointed
d 2009/04/24 13:00:43 World Community Grid [checkpoint_debug] result E000526_375A_00417s00b_1 checkpointed
c 2009/04/24 13:03:16 World Community Grid [checkpoint_debug] result E000526_357A_00417q00z_0 checkpointed
b 2009/04/24 13:16:48 World Community Grid [checkpoint_debug] result dddt1102e0279_100386_0 checkpointed
a 2009/04/24 13:19:12 World Community Grid [checkpoint_debug] result R00272_8fad0eb181248669d23fa71606c8fe4e_03_011_0 checkpointed
d 2009/04/24 13:22:43 World Community Grid [checkpoint_debug] result E000526_375A_00417s00b_1 checkpointed
c 2009/04/24 13:27:28 World Community Grid [checkpoint_debug] result E000526_357A_00417q00z_0 checkpointed

When looking in the slots, the time stamps change synchronous to the message log.

Noted is that projects that don't ask for write permission such as rosetta mini log theirs every few minutes.

---

Coelum Non Animum Mutant, Qui Trans Mare Currunt

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