Moo! Wrapper freezes about 96-99% in and CPU (and presumably GPU) usage drops to nil for it.

If I suspend and restart the stalled WU, it immediately completes like nothing bad happened.

This problem seems to happen with some but not all WUs -- I'm guessing they sometimes/somehow clear out on their own after some timeout period, but if I'm watching BOINC I often spot this. No doubt this is reducing my GPU's effectiveness as it's sitting idle more.

Contents of stderr.txt (which seems to contain sufficient identifying information):

09:46:47 (3724): wrapper: starting v1.3.9.7
09:46:47 (3724): device: 1 x GeForce GTS 250 (driver version 320.18, CUDA version 5.50, compute capability 1.1, 1024MB, 971MB available, 560 GFLOPS peak)
09:46:47 (3724): checkpoint interval: 15 min (task 336000 GFLOPS, 10 min)
09:46:47 (3724): wrapper: running dnetc518-win32-x86-cuda31.exe (-ini dnetc.ini -runoffline -multiok=1) - attempt 1/10

dnetc v2.9109-518-CTR-10092920 for CUDA 3.1 on Win32 (WindowsNT 5.1).
Using email address (distributed.net ID) 'switeck@hotmail.com'

[Feb 12 15:46:47 UTC] nvcuda.dll Version: 6.14.13.2018
[Feb 12 15:46:47 UTC] Automatic processor type detection found
                      a GeForce GTS 250 (128 SPs) processor.
[Feb 12 15:46:47 UTC] RC5-72: using core #0 (CUDA 1-pipe 64-thd).
[Feb 12 15:46:47 UTC] RC5-72: Loaded D2:4A9F6109:00000000:64*2^32
[Feb 12 15:46:47 UTC] RC5-72: 2 packets (128.00 stats units) remain in
                      in.r72
[Feb 12 15:46:47 UTC] RC5-72: 0 packets are in out.r72
[Feb 12 15:46:47 UTC] 1 cruncher has been started.
[Feb 12 16:15:19 UTC] RC5-72: Completed D2:4A9F6109:00000000 (64.00 stats units)
                      0.00:28:31.84 - [160,574,156 keys/s]
[Feb 12 16:15:19 UTC] RC5-72: Loaded D2:4A9F6149:00000000:64*2^32
[Feb 12 16:15:19 UTC] RC5-72: Summary: 1 packet (64.00 stats units)
                      0.00:28:31.84 - [160.57 Mkeys/s]
[Feb 12 16:15:19 UTC] RC5-72: 1 packet (64.00 stats units) remains in in.r72
                      Projected ideal time to completion: 0.00:27:44.00
[Feb 12 16:15:19 UTC] RC5-72: 1 packet (64.00 stats units) is in out.r72
[Feb 12 16:43:51 UTC] RC5-72: Completed D2:4A9F6149:00000000 (64.00 stats units)
                      0.00:28:31.68 - [160,588,885 keys/s]
[Feb 12 16:43:51 UTC] RC5-72: Loaded D2:4A9F6189:00000000:64*2^32
[Feb 12 16:43:51 UTC] RC5-72: Summary: 2 packets (128.00 stats units)
                      0.00:57:03.53 - [160.58 Mkeys/s]
[Feb 12 16:43:51 UTC] RC5-72: 0 packets remain in in.r72
[Feb 12 16:43:51 UTC] RC5-72: 2 packets (128.00 stats units) are in out.r72
[Feb 12 17:12:31 UTC] RC5-72: Completed D2:4A9F6189:00000000 (64.00 stats units)
                      0.00:28:38.85 - [159,918,822 keys/s]
[Feb 12 17:12:31 UTC] Shutdown - packet limit exceeded.
[Feb 12 17:12:31 UTC] RC5-72: Summary: 3 packets (192.00 stats units)
                      0.01:25:42.39 - [160.36 Mkeys/s]
[Feb 12 17:12:31 UTC] RC5-72: 0 packets remain in in.r72
[Feb 12 17:12:31 UTC] RC5-72: 3 packets (192.00 stats units) are in out.r72
[Feb 12 17:12:31 UTC] *Break* Shutting down...
[Feb 12 17:12:31 UTC] Shutdown complete.

Moo! Wrapper freezes about 96-99% in and CPU (and presumably GPU) usage drops to nil for it.

If I suspend and restart the stalled WU, it immediately completes like nothing bad happened.

This problem seems to happen with some but not all WUs -- I'm guessing they sometimes/somehow clear out on their own after some timeout period, but if I'm watching BOINC I often spot this. No doubt this is reducing my GPU's effectiveness as it's sitting idle more.

Does this happen alot, or just every now and then? Because if just every now and then it could be the benchmarking that is causing the problems and that is fixable thru this file:
<cc_config>
<options>
<skip_cpu_benchmarks>1</skip_cpu_benchmarks>
</options>
</cc_config>

Copy and past those lines into NOTEPAD and then save it as "cc_config.xml", a txt type file, in the Boinc folder. Then stop and restart Boinc and it should be okay. When the benchmarks are done, mostly weekly, all the crunching stops and after it is done it is supposed to start back up again, sometimes the gpu does not get the info to restart and you see what you are seeing.

Benchmarking is how Boinc decides how many workunits to download when you ask for new tasks, ie are you able to crunch units in 10 minutes or 3 hours. You are a long time cruncher and the benchmarking is not exactly going to show your pc is suddenly running at turbo speed or anything, it is what it is and always has been.

The problem happens often enough that I've spotted it maybe 5 times.

I've seen the benchmarking tests before -- they seem to occur after rebooting and first starting up windows + BOINC. (I only typically reboot about once a week.)
The freezes I'm seeing are not that.

This tells me there's something more sinister happening:
"[Feb 12 17:12:31 UTC] Shutdown - packet limit exceeded."
"[Feb 12 17:12:31 UTC] *Break* Shutting down..."

...but likely only the programmers can make sense of that. :(

The problem happens often enough that I've spotted it maybe 5 times.

I've seen the benchmarking tests before -- they seem to occur after rebooting and first starting up windows + BOINC. (I only typically reboot about once a week.)
The freezes I'm seeing are not that.

This tells me there's something more sinister happening:
"[Feb 12 17:12:31 UTC] Shutdown - packet limit exceeded."
"[Feb 12 17:12:31 UTC] *Break* Shutting down..."

...but likely only the programmers can make sense of that. :(

Yes the benchmarks occur weekly if you don't reboot, upon some reboots and anytime you do an upgrade to Boinc itself.

I do not know what that error message means so you could be right about only the programmers having a clue. Sorry.

This tells me there's something more sinister happening:
"[Feb 12 17:12:31 UTC] Shutdown - packet limit exceeded."
"[Feb 12 17:12:31 UTC] *Break* Shutting down..."

A bit late response but.. that's a normal shutdown sequence for the Dnet Client. If the WU doesn't complete after that it might be a problem in our wrapper or in BOINC Client itself where they don't see the completion (or the process don't actually terminate).

-w