well i tried suspending all projects but Milkyway@Home, and the "drained cache" problems persisted. the same thing happened when i suspended all projects but SETI@Home. so i enabled the <coproc_debug> and <dcf_debug> logging flags to see if it would reveal anymore clues through the BOINC event log. the <coproc_debug> flag didn't report anything out of the ordinary, and i really didn't let BOINC run long enough to note how DCF was changing over time. that said, for Milkyway@Home, my estimated run times are right in line w/ my actual run times, and so it was no surprise to see a DCF of ~1...so why my MW@H cache would drain completely before refilling is beyond me. SETI@Home on the other hand has a DCF of 0.015445 for this host, and the last check i made before that , it was at 0.02xxxx...so its as though the DCF keeps getting smaller. if this figure seems out of line for an HD 5870 capable of 2720 GFLOPS, then i'd be interested in doing whatever is necessary to correct that value...although i'm skeptical that it'll do anything for me, seeing as how my estimated run times and DCF for Milkyway@Home are right where they should be, and yet i'm still having problem maintaining a cache.

---

well i tried suspending all projects but Milkyway@Home, and the "drained cache" problems persisted. the same thing happened when i suspended all projects but SETI@Home. so i enabled the <coproc_debug> and <dcf_debug> logging flags to see if it would reveal anymore clues through the BOINC event log. the <coproc_debug> flag didn't report anything out of the ordinary, and i really didn't let BOINC run long enough to note how DCF was changing over time. that said, for Milkyway@Home, my estimated run times are right in line w/ my actual run times, and so it was no surprise to see a DCF of ~1...so why my MW@H cache would drain completely before refilling is beyond me. SETI@Home on the other hand has a DCF of 0.015445 for this host, and the last check i made before that , it was at 0.02xxxx...so its as though the DCF keeps getting smaller. if this figure seems out of line for an HD 5870 capable of 2720 GFLOPS, then i'd be interested in doing whatever is necessary to correct that value...although i'm skeptical that it'll do anything for me, seeing as how my estimated run times and DCF for Milkyway@Home are right where they should be, and yet i'm still having problem maintaining a cache.

you can zero out your debts by putting this into your cc_config.xml file:
<zero_debts>1</zero_debts>. It is recommended that you only use it once then remove it, but I know some people who just left it in there.

you can zero out your debts by putting this into your cc_config.xml file:
<zero_debts>1</zero_debts>. It is recommended that you only use it once then remove it, but I know some people who just left it in there.

thanks for the additional advice, but i've made some changes that won't allow me to test this right now. i've since reverted back to BOINC v6.12.43 and MW@H Separation v0.82 for a few reasons:

1) while not being able to maintain MW@H and S@H caches w/ either BOINC v6.13.xx or v7.xx.xx wasn't the end of the world, it was enough to bother me. b/c there would sometimes be dead time between the completion of the last task in the cache and the downloaded/start of new wrk, my production was becoming unacceptably low for the hardware i'm running.

2) for some reason, the Separation v1.02 tasks are causing Catalyst driver resets, which i have been unable to get to the bottom of.

so in the mean time, i simply run MW@H v0.82 sometimes, and S@H sometimes (though obviously not at the same time b/c BOINC v6.12.xx doesn't recognize the <exclude_gpu> command, and i can't run a higher BOINC version without having problems maintaining a cache). obviously this requires some babysitting, but i have little choice at this point. i'm hoping to upgrade the motherboard (something w/ more PCIe bandwidth than what i have now) and OS (Win7 x64) soon, reload BOINC and my projects, and see if that eliminates any of my existing problems or creates new ones.

---

you can zero out your debts by putting this into your cc_config.xml file:
<zero_debts>1</zero_debts>. It is recommended that you only use it once then remove it, but I know some people who just left it in there.

thanks for the additional advice, but i've made some changes that won't allow me to test this right now. i've since reverted back to BOINC v6.12.43 and MW@H Separation v0.82 for a few reasons:

1) while not being able to maintain MW@H and S@H caches w/ either BOINC v6.13.xx or v7.xx.xx wasn't the end of the world, it was enough to bother me. b/c there would sometimes be dead time between the completion of the last task in the cache and the downloaded/start of new wrk, my production was becoming unacceptably low for the hardware i'm running.

2) for some reason, the Separation v1.02 tasks are causing Catalyst driver resets, which i have been unable to get to the bottom of.

so in the mean time, i simply run MW@H v0.82 sometimes, and S@H sometimes (though obviously not at the same time b/c BOINC v6.12.xx doesn't recognize the <exclude_gpu> command, and i can't run a higher BOINC version without having problems maintaining a cache). obviously this requires some babysitting, but i have little choice at this point. i'm hoping to upgrade the motherboard (something w/ more PCIe bandwidth than what i have now) and OS (Win7 x64) soon, reload BOINC and my projects, and see if that eliminates any of my existing problems or creates new ones.

I run the exact same cpu and use an ASRock 990FX Extreme4 motherboard with 16 gig of ram with dual 5770 gpu's in it. Because the 5770 is not a dual precision gpu it is crunching for Moo. It is here:
http://moowrap.net/show_host_detail.php?hostid=8022

It has 3 pci-e slots but the 3rd is on the very edge of the mb and isn't very usable. Memory was cheap at Micro-Center, less than $100 for 4 4gb chips. Knock on wood I am not having ANY troubles with it!!! I am running 6 Poem cpu units and 1 Moo gpu unit all at once, Moo uses all gpu's to run one unit. The OS is Win7 64bit Ultimate.

I would first upgrade your memory to at least 8 gig but probably 16 gig if it were my pc. There have been studies done that say a pci-e slot is not the slow-down people think it is, so that may not be your problem.

---

I would first upgrade your memory to at least 8 gig but probably 16 gig if it were my pc. There have been studies done that say a pci-e slot is not the slow-down people think it is, so that may not be your problem.

well i'm running WinXP x32 right now, so there's no sense in moving to 8GB or 16GB of memory until i upgrade to a 64-bit OS first. nevertheless, i do currently have 8GB of memory, so as soon as i make the jump to Win7 x64, it'll start recognizing more than just 3.25GB. also, i didn't intend to imply that PCIe bandwidth was part of my problem...its just one of the upgrades i'd like to make at the same time i move to Win7 x64 on an SSD...that way i can run a 3rd GPU in the future if i so desire...

at any rate, i'm not gonna worry about the problems i was having before b/c the may or may not still exist after i switch to Win7 x64. we'll see if that eliminates them when the time comes (it may be a while before i have time to upgrade this machine), and/or creates any new problems...but i'll deal with it then.

---

I would first upgrade your memory to at least 8 gig but probably 16 gig if it were my pc. There have been studies done that say a pci-e slot is not the slow-down people think it is, so that may not be your problem.

well i'm running WinXP x32 right now, so there's no sense in moving to 8GB or 16GB of memory until i upgrade to a 64-bit OS first. nevertheless, i do currently have 8GB of memory, so as soon as i make the jump to Win7 x64, it'll start recognizing more than just 3.25GB. also, i didn't intend to imply that PCIe bandwidth was part of my problem...its just one of the upgrades i'd like to make at the same time i move to Win7 x64 on an SSD...that way i can run a 3rd GPU in the future if i so desire...

at any rate, i'm not gonna worry about the problems i was having before b/c the may or may not still exist after i switch to Win7 x64. we'll see if that eliminates them when the time comes (it may be a while before i have time to upgrade this machine), and/or creates any new problems...but i'll deal with it then.

Ahhh yes you are correct more than 4 gig would not be helpful under XP!

One thing I did, I install Win7 on my pc's more than once due to using used parts all the time, I got an 8 gig usb stick and after making it bootable copied the Win7 dvd onto it. It makes Win7 load up almost twice as fast as using the dvd, it also means I don't have to put a dvd drive in each machine early on.

Ahhh yes you are correct more than 4 gig would not be helpful under XP!

One thing I did, I install Win7 on my pc's more than once due to using used parts all the time, I got an 8 gig usb stick and after making it bootable copied the Win7 dvd onto it. It makes Win7 load up almost twice as fast as using the dvd, it also means I don't have to put a dvd drive in each machine early on.

thanks for the suggestion...that's definitely something i'll want to do, b/c i plan on converting more than one machine over to Win7 X64 in the near future...

---

Ahhh yes you are correct more than 4 gig would not be helpful under XP!

One thing I did, I install Win7 on my pc's more than once due to using used parts all the time, I got an 8 gig usb stick and after making it bootable copied the Win7 dvd onto it. It makes Win7 load up almost twice as fast as using the dvd, it also means I don't have to put a dvd drive in each machine early on.

thanks for the suggestion...that's definitely something i'll want to do, b/c i plan on converting more than one machine over to Win7 X64 in the near future...

I did that too! I am finally all Win7 except for one MS Windows Home Server and I do not use it as a backup device, I use it to manage my network.