I have a problem occasionally getting flooded with work units if I am getting both CPU and GPU tasks toogether ..I am hoping the new release of BOINC due out shortly will resolve this. In the short term I have actually been hand managing by raising my cpu cache when I want tasks and then lowering it once a batch has been received. I continue to get GPU tasks even when the cache is set to 0 days.

I may be wrong but, I noticed w/6.10.58 GPU WU's caused the time (on cached wu's) to lower causing extra wu's to download.

When I upgrade to 7.0.28 and 7.0.42 the problem stopped.

Might be worth a try.

I also noticed an increasing number of repair jobs with 10 days deadlines here. It seems that those are getting more and more. There are quite a lot of replication number _0 wingmen with a "detached" status.

I also received a repair job (10 days deadline) from a wingman who had been given a "too late" "no reply" status only 50 minutes after he/she got the task. See list below (**), the example in the list has been given too late "no reply" status even immediately.

These are the error logs from the wingmen tasks i have in my results page. I have never seen an error in a GFAM tasks on my machines. My machine is running a GFAM-only profile with Boinc 6.10.58-64bit on Ubuntu. Maybe this helps:

Result Name: GFAM_ x1AWQ_ hCypA_ 0087023_ 0212_ 0--
<core_client_version>6.10.17</core_client_version>
<![CDATA[
<message>
too many exit(0)s
</message>
]]>

Result Name: GFAM_ x1AWQ_ hCypA_ 0087086_ 0171_ 0--
<core_client_version>7.0.28</core_client_version>
<![CDATA[
<message>
couldn't start CreateProcess() failed - A required privilege is not held by the client. (0x522): -148
</message>
]]>

Result Name: GFAM_ x1BCK_ hCypA_ 0087200_ 0042_ 0-- --> detached

GFAM_ x1CWJ_ hCypA_ 0087786_ 0066_ 0--
<core_client_version>6.2.28</core_client_version>
<![CDATA[
<message>
too many exit(0)s
</message>
]]>

(**) GFAM_ x1CWK_ hCypA_ 0087926_ 0005_ 0-- - No Reply 3/29/13 11:35:23 3/29/13 11:35:43 0.00 0.0 / 0.0

next 2 replications are from same task:

Result Name: GFAM_ x1FGL_ hCypA_ 0088192_ 0065_ 0--
<core_client_version>6.10.58</core_client_version>
<![CDATA[
<message>
too many exit(0)s
</message>
]]>

Result Name: GFAM_ x1FGL_ hCypA_ 0088192_ 0065_ 2--
<core_client_version>7.0.28</core_client_version>
<![CDATA[
<message>
couldn't start Can't write init file: -108: -108
</message>
]]>

Apart from this, i'm not getting flooded with jobs or anything.

'Always' is a big statement, but yes, 6.0.17 is one of those versions to quickly skip past... It's though also quite likely it's a Linux distro [Is it?] that is overdue for an upgrade, so the repo can fetch a newer client with that.

A tech [armstrdj], has met the suggestion favorable to add future updates with more client info [CPU/platform] in the Result Log, so we wont have to second guess, or ask again what hardware/OS we're dealing with when offering help.

Noted was by uplinger on behalf of knreed a few days ago that 'user aborts' no longer only go to the repair queue, but also to regular crunchers [did not say what their deadlines were but saw they got full 10 days from date of submission, not 10 days from original date of copy _0. The 'user aborts' for v7 client still get mislabeled with 'error', so it could be those too.

And yes, there were a bunch of verifiers that got circulated with 10 days [had a boat load]. Saw this on GFAM and reported this few days ago too to techs. Now they show, for me at least, with 4 days again... since sometime the 29th.

Forums have been going and coming for me at this time, suspended client networking because of persistent upload download fails, so taking it slow at this time.