the only thing - BOINC do not want to get or the project not sending the 2nd WU at all. and basically it starts to download new WU only when it finish to crunch. this means somewhat couple of minutes of idling.

the only thing - BOINC do not want to get or the project not sending the 2nd WU at all. and basically it starts to download new WU only when it finish to crunch. this means somewhat couple of minutes of idling.

I'm using v6.12.4 also and am seeing this problem in all GPU projects. It seems that the GPU queue slowly shrinks and has to be constantly enlarged to maintain the same size. It's especially noticeable in Collatz since the queue is much larger. I believe this started in BOINC v6.11.7 and is still unfixed. The only way I've found to reset the queue size is to reinstall v6.11.6 or earlier (I generally use v6.10.58 for this), let it run until the until the work is downloaded then install v6.12.4 again. At that point the proper queue is reinstated but slowly starts to shrink again. Anyone else noticing this?

That sounds like awful babysitting. Any benefit to not sticking with 6.10.58 for now?

the only thing - BOINC do not want to get or the project not sending the 2nd WU at all. and basically it starts to download new WU only when it finish to crunch. this means somewhat couple of minutes of idling.

I'm using v6.12.4 also and am seeing this problem in all GPU projects. It seems that the GPU queue slowly shrinks and has to be constantly enlarged to maintain the same size. It's especially noticeable in Collatz since the queue is much larger. I believe this started in BOINC v6.11.7 and is still unfixed. The only way I've found to reset the queue size is to reinstall v6.11.6 or earlier (I generally use v6.10.58 for this), let it run until the until the work is downloaded then install v6.12.4 again. At that point the proper queue is reinstated but slowly starts to shrink again. Anyone else noticing this?

Well, in a way that's to be expected. v6.12.4 is prominently marked (MAY BE UNSTABLE - USE ONLY FOR TESTING) - you've obviously found an instability in the cache size algorithm. But unless you report test results, and give the developers some data to work from, the fixing process is inevitably slow.

As it happens, a very similar report appeared on boinc_alpha last week, again with reference to Collatz. And again, it refers to v6.12.4: if you've been seeing it since v6.11.7, may I ask why it hasn't been reported until now?

Hi Richard, have noticed many of your posts on the list and consider you one of the "voices of reason" there. I'm not a programmer (was a network manager and network VAR before retirement) so feel a bit out of place there. What's your take on the proposed new credit system that seems to be such a focus of effort?

how i can get inside that alpha list? there are couple onther bug I see on 6.11.7-8-9 as well as 6.12.4 versions. one of then boinc manager used to disappear although my rig continue to crunch. I'm opening manager and evething works fine, but this stuff was not on 6.10.58

how i can get inside that alpha list? there are couple onther bug I see on 6.11.7-8-9 as well as 6.12.4 versions. one of then boinc manager used to disappear although my rig continue to crunch. I'm opening manager and evething works fine, but this stuff was not on 6.10.58

CTAPbIi - the only thing - BOINC do not want to get or the project not sending the 2nd WU at all. and basically it starts to download new WU only when it finish to crunch. this means somewhat couple of minutes of idling.

Date: Thu, 04 Nov 2010 19:07:03 -0700
From: David Anderson
Subject: Re: [boinc_alpha] Boinc 6.12.4 GPU issues
To: boinc_alpha

Problem found (groan):

- bool is_gpu_active = !is_active && !gpu_suspend_reason;
+ bool is_gpu_active = is_active && !gpu_suspend_reason;

This fix will be in the next release.
Your gpu_active_grac will gradually return to the correct value.
In the meantime you can manually fix it in client_state.xml

-- David

<time_stats>
    <on_frac>0.998909</on_frac>
    <connected_frac>1.000000</connected_frac>
    <active_frac>0.999975</active_frac>
    <gpu_active_frac>0.174423</gpu_active_frac>
    <last_update>1288914349.413624</last_update>
</time_stats>

I've noticed that sometimes when I close BOINC manager it just exits without popping up the dialogue to close the project apps. For a LONG time now sometimes BOINC will crash and refuse to start. When this happens killing boinctray.exe in Task Manager always allows BOINC to restart. In fact commenting out boinctray.exe in startup seems to solve some of the above problems.

Richard, what exactly is the purpose of boinctray.exe? As I remember it had something to do with Vista, but never really understood why it's needed and always installed with every new BOINC version.

We were having a chat - off-topic, admittedly - in the hardware area about the curious cases of the incredible shrinking cache and high priority running - in the latest test versions only.

The cause has been found. In your client_state.xml file, you'll find a section like this:

<time_stats>
    <on_frac>0.998909</on_frac>
    <connected_frac>1.000000</connected_frac>
    <active_frac>0.999975</active_frac>
    <gpu_active_frac>0.174423</gpu_active_frac>
    <last_update>1288914349.413624</last_update>
</time_stats>

If you change that <gpu_active_frac> to 1.000000, things will return to normal. That should be quicker than reverting to v6.10.58 ;-)

The fix (a one character typo corrected) should be in v6.12.5

I've noticed that sometimes when I close BOINC manager it just exits without popping up the dialogue to close the project apps. For a LONG time now sometimes BOINC will crash and refuse to start. When this happens killing boinctray.exe in Task Manager always allows BOINC to restart. In fact commenting out boinctray.exe in startup seems to solve some of the above problems.

Richard, what exactly is the purpose of boinctray.exe? As I remember it had something to do with Vista, but never really understood why it's needed and always installed with every new BOINC version.

In theory, boinctray.exe is a simple utility which just monitors for mouse and keyboard activity. That is used to judge whether a user is active on the computer, and hence give effect to BOINC's preferences to suspend activities while the computer is in use, if you use any of those options.

I'm not sure how boinctray communicates with the rest of boinc. I don't think it's the TCP/IP used between the core client and the manager: more likely to be the shared memory segment also used for communicating between the core client and the science applications. That might explain why a problem with boinctray blocks the rest of boinc from running.

If you don't use 'run according to preferences', your workround should be fine. But for the benefit of other volunteers who do want to use those settings, it would be better to track down the cause properly. Wild speculation as I type: do you use any special input hardware with non-standard or third-party drivers? Given boinctray's job, it should only be in some area like that that problems could arise.

Thanks for the explanation. I have no special input devices, only generic keyboards and plain vanilla PS/2 or USB mice. No special drivers are loaded for either. Some but not all of the machines are on KVM switches, also with no special drivers loaded. This issue happens on all 9 of my machines from time to time. BOINC manager crashes or loses connection (but boinc.exe and the apps continue) and when reloaded fails to find a BOINC client. Killing boinctray.exe almost always allows the client to reconnect. As CTAPbIi reported above the issue of BOINC manager exiting and/or losing connection to the client has definitely become more common since 6.10.58.

Thanks for the explanation. I have no special input devices, only generic keyboards and plain vanilla PS/2 or USB mice. No special drivers are loaded for either. Some but not all of the machines are on KVM switches, also with no special drivers loaded. This issue happens on all 9 of my machines from time to time. BOINC manager crashes or loses connection (but boinc.exe and the apps continue) and when reloaded fails to find a BOINC client. Killing boinctray.exe almost always allows the client to reconnect. As CTAPbIi reported above the issue of BOINC manager exiting and/or losing connection to the client has definitely become more common since 6.10.58.

Do you use a proxy server?