and we're back

Is there any advantage to raising the CPU% used in ati5_nocal other than doing the wu faster?

---

That is really an open ended question ... Yes freeing up a core does help GPU performance, but does that empty core do more work than you gained?

My i5 doesn't seem to boost the GPU enough to warrant a core shut down for 2 MB tasks. If I was running 3 or 4, then yes.

If CPU heat is an issue, then shutdown a core.

I think I do see an improvement in AP GPU tasks with 1 core shutdown, but it's hard to tell since those buggers are hard to get your hands on.

One hint ... stop your network communication, run it for a few hours, make a change, run for a few hours ... it will give you a good idea of what your run times are changing.

---

It always depends on the CPU/GPU combo.
With a high end GPU you always benefit freeing a CPU core.

---

With each crime and every kindness we birth our future.

For nearly 24 hours i'm not getting *ANY* work for the CPU, only work for GPU!
I didn't change anything, i don't get it... :/

---

Aloha, Uli

For nearly 24 hours i'm not getting *ANY* work for the CPU, only work for GPU!
I didn't change anything, i don't get it... :/

The 'tasks limit in progress' reached for the GPU (or set WU cache)?

---

The 'tasks limit in progress' reached for the GPU (or set WU cache)?

I have 2 CPUs and 2 GPUs and 139 tasks in progress.
This is what i get:

08/07/2015 18:57:40 | SETI@home | Computation for task 19ja15ab.29055.20324.438086664197.12.134_1 finished
08/07/2015 18:57:40 | SETI@home | Starting task 19ja15ab.29055.20324.438086664197.12.199_1
08/07/2015 18:57:40 | SETI@home | [cpu_sched] Starting task 19ja15ab.29055.20324.438086664197.12.199_1 using setiathome_v7 version 700 (cuda50) in slot 2
08/07/2015 18:57:42 | SETI@home | Started upload of 19ja15ab.29055.20324.438086664197.12.134_1_0
08/07/2015 18:57:48 | SETI@home | Finished upload of 19ja15ab.29055.20324.438086664197.12.134_1_0
08/07/2015 18:57:50 | SETI@home | Sending scheduler request: To report completed tasks.
08/07/2015 18:57:50 | SETI@home | Reporting 1 completed tasks
08/07/2015 18:57:50 | SETI@home | Requesting new tasks for CPU and NVIDIA GPU
08/07/2015 18:57:53 | SETI@home | Scheduler request completed: got 1 new tasks
08/07/2015 18:57:55 | SETI@home | Started download of 10fe15aa.9888.9065.438086664197.12.123
08/07/2015 18:57:59 | SETI@home | Finished download of 10fe15aa.9888.9065.438086664197.12.123

Of course the single downloaded WU is for the GPU!? :(
So my CPU crunches Milkyway, the backup project.
Things get worse and worse...

---

Aloha, Uli

I attribute it to BOINC 7.2.33 which seems to be the best version I've come across.

Well, take a look at my active hosts and see which BOINC version I'm running....on all of them. :^) I still average a couple of truncations a day, I think, though as I mentioned, only(!) about 5 a month end up Invalid.

I gave it some more thought and realized sometime between using the Commode version and the regular version I had moved the BOINC Data folder to a 2nd hard drive. Maybe having the Data folder on a different HD than the OS makes a difference? I dunno, just trying to guess why I don't seem to be having the problem anymore...

08/07/2015 19:14:55 | SETI@home | Finished upload of 19ja15ab.29055.20324.438086664197.12.199_1_0
08/07/2015 19:19:52 | SETI@home | Sending scheduler request: To report completed tasks.
08/07/2015 19:19:52 | SETI@home | Reporting 1 completed tasks
08/07/2015 19:19:52 | SETI@home | Requesting new tasks for CPU
08/07/2015 19:19:55 | SETI@home | Scheduler request completed: got 0 new tasks
08/07/2015 19:19:55 | SETI@home | No tasks sent
08/07/2015 19:19:55 | SETI@home | No tasks are available for AstroPulse v7
08/07/2015 19:25:15 | Milkyway@Home | Computation for task de_80_DR8_Rev_8_5_00004_1434551187_10506855_0 finished
08/07/2015 19:25:15 | Milkyway@Home | Sending scheduler request: To report completed tasks.

Look at this, i have selected to download other WUs, if AP is not available, which obviously works for the GPU but *NOT* for the CPU. This is server side related, *NOT* on my end!

---

Aloha, Uli

Don't look now, but we got a new dataset splitting off some AP work..........
Meow alert.

---

Excuse me if I am hard to understand at times.......I've had a difficult few lives.

I attribute it to BOINC 7.2.33 which seems to be the best version I've come across.

Well, take a look at my active hosts and see which BOINC version I'm running....on all of them. :^) I still average a couple of truncations a day, I think, though as I mentioned, only(!) about 5 a month end up Invalid.

I gave it some more thought and realized sometime between using the Commode version and the regular version I had moved the BOINC Data folder to a 2nd hard drive. Maybe having the Data folder on a different HD than the OS makes a difference? I dunno, just trying to guess why I don't seem to be having the problem anymore...

Do you have a different setting for "write caching" on the 2nd drive? I remember speculating that write caching might be a factor, back when we were initially trying to diagnose the problem. Unfortunately, after trying it with the setting both enabled (my default) and disabled, I didn't find any difference in behavior so I pretty much discarded that theory. Maybe there's another drive setting that could be in play.

I'm in the same boat ... with 350.12 I suddenly stopped downloading AP GPU tasks.

So I reverted to 347.88 and reinstalled Lunatics (AP worked fine then), now it's hard to find a single std_err for ANY MB GPU task that is not empty. DAMN

I was thinking the same, did a Windows update change my HD cache settings some where along the line? Is it the driver? although many other people use it!

Maybe I should move my BOINC folder to my SSD.

IDK, I'm confuzzled as to why shit happens.

---

Interesting to see some of your SETI MB get hit by the blank stderr.txt bug. I've only experienced it on MilkyWay tasks that complete in under 50 seconds. I thought the short runtimes of those task might have some bearing on the problem. Interesting to see the problem on a standard MB GPU task that completes in the normal 20 minute range. You would have to run the beta 7.6.2 BoincManager and set some debug flags to help Richard out with the analyzing of this problem. I'm doing that now and have caught one invalid MW blank stderr.txt task already and still looking for more in the logs.

Good luck.

Keith

[Edit} I am running SSD's so doesn't seem to help the problem.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Interesting to see some of your SETI MB get hit by the blank stderr.txt bug. I've only experienced it on MilkyWay tasks that complete in under 50 seconds. I thought the short runtimes of those task might have some bearing on the problem. Interesting to see the problem on a standard MB GPU task that completes in the normal 20 minute range. You would have to run the beta 7.6.2 BoincManager and set some debug flags to help Richard out with the analyzing of this problem. I'm doing that now and have caught one invalid MW blank stderr.txt task already and still looking for more in the logs.

Good luck.

Keith

[Edit} I am running SSD's so doesn't seem to help the problem.

You have another PM, but it's bedtime on this side of the pond. I'll look to see if you've caught another one in the morning.

Just picked up a few APs!!! :-) I hope I get more. :-)

---

TimeLord04
Have TARDIS, will travel...
Come along K-9!
Join Calm Chaos

I attribute it to BOINC 7.2.33 which seems to be the best version I've come across.

Well, take a look at my active hosts and see which BOINC version I'm running....on all of them. :^) I still average a couple of truncations a day, I think, though as I mentioned, only(!) about 5 a month end up Invalid.

I gave it some more thought and realized sometime between using the Commode version and the regular version I had moved the BOINC Data folder to a 2nd hard drive. Maybe having the Data folder on a different HD than the OS makes a difference? I dunno, just trying to guess why I don't seem to be having the problem anymore...

Do you have a different setting for "write caching" on the 2nd drive? I remember speculating that write caching might be a factor, back when we were initially trying to diagnose the problem. Unfortunately, after trying it with the setting both enabled (my default) and disabled, I didn't find any difference in behavior so I pretty much discarded that theory. Maybe there's another drive setting that could be in play.

Same write caching on both drives. The OS is on an old SATA drive, the Data folder is on an older PATA drive with just other data on it. I did revert back to the first driver that works with Win 8.1 a few weeks ago, seems to work better with my GTS250 than the 337.88 version I was using earlier. I wasn't having the problem with 337.88 either though.

08/07/2015 19:14:55 | SETI@home | Finished upload of 19ja15ab.29055.20324.438086664197.12.199_1_0
08/07/2015 19:19:52 | SETI@home | Sending scheduler request: To report completed tasks.
08/07/2015 19:19:52 | SETI@home | Reporting 1 completed tasks
08/07/2015 19:19:52 | SETI@home | Requesting new tasks for CPU
08/07/2015 19:19:55 | SETI@home | Scheduler request completed: got 0 new tasks
08/07/2015 19:19:55 | SETI@home | No tasks sent
08/07/2015 19:19:55 | SETI@home | No tasks are available for AstroPulse v7
08/07/2015 19:25:15 | Milkyway@Home | Computation for task de_80_DR8_Rev_8_5_00004_1434551187_10506855_0 finished
08/07/2015 19:25:15 | Milkyway@Home | Sending scheduler request: To report completed tasks.

Look at this, i have selected to download other WUs, if AP is not available, which obviously works for the GPU but *NOT* for the CPU. This is server side related, *NOT* on my end!

If I check all (CPU, Intel iGPU, ATI GPU and NV GPU (although no ATI GPU installed)) and in my app_info.xml file are AP and SETI entries for all 3 devices, my PC (CPU and GPUs) get AP and SETI WUs if I uncheck SETI, check AP and check 'If no work for selected applications is available, accept work from other applications'.
Resource share 1000000 for SETI, 0 for Milkyway.

It looks like your PC got now AP WUs for the CPU...
Do you changed something in app_info.xml file, there is still a fine SETI entry for CPU?

---

I attribute it to BOINC 7.2.33 which seems to be the best version I've come across.

Well, take a look at my active hosts and see which BOINC version I'm running....on all of them. :^) I still average a couple of truncations a day, I think, though as I mentioned, only(!) about 5 a month end up Invalid.

I gave it some more thought and realized sometime between using the Commode version and the regular version I had moved the BOINC Data folder to a 2nd hard drive. Maybe having the Data folder on a different HD than the OS makes a difference? I dunno, just trying to guess why I don't seem to be having the problem anymore...

Do you have a different setting for "write caching" on the 2nd drive? I remember speculating that write caching might be a factor, back when we were initially trying to diagnose the problem. Unfortunately, after trying it with the setting both enabled (my default) and disabled, I didn't find any difference in behavior so I pretty much discarded that theory. Maybe there's another drive setting that could be in play.

Same write caching on both drives. The OS is on an old SATA drive, the Data folder is on an older PATA drive with just other data on it. I did revert back to the first driver that works with Win 8.1 a few weeks ago, seems to work better with my GTS250 than the 337.88 version I was using earlier. I wasn't having the problem with 337.88 either though.

Nevermind. Seems now that I'm looking I'm finding a few truncated stderr.txt. Time to go back to the Commode build. No problem, the .exe is still in my setiathome.berkeley.edu folder, I'll just change the names in my app_info file back before I get any of those Instant Invalids.
Oh, well...

(...)
It looks like your PC got now AP WUs for the CPU...
Do you changed something in app_info.xml file, there is still a fine SETI entry for CPU?

It seems it sorted out. The only thing i did was, to select all apps and submit the changes. Then i waited a few minutes and selected AP7 only and other apps yes, if AP7 is not available.
It is like sometimes in Windows: An option is selected, but doesn't work. So you unselect it and hit "ok". Then you select the option again and hit "ok" and "magically" now the option works...

---

Aloha, Uli

I gave it some more thought and realized sometime between using the Commode version and the regular version I had moved the BOINC Data folder to a 2nd hard drive. Maybe having the Data folder on a different HD than the OS makes a difference? I dunno, just trying to guess why I don't seem to be having the problem anymore...

Do you have a different setting for "write caching" on the 2nd drive? I remember speculating that write caching might be a factor, back when we were initially trying to diagnose the problem. Unfortunately, after trying it with the setting both enabled (my default) and disabled, I didn't find any difference in behavior so I pretty much discarded that theory. Maybe there's another drive setting that could be in play.

Same write caching on both drives. The OS is on an old SATA drive, the Data folder is on an older PATA drive with just other data on it. I did revert back to the first driver that works with Win 8.1 a few weeks ago, seems to work better with my GTS250 than the 337.88 version I was using earlier. I wasn't having the problem with 337.88 either though.

Nevermind. Seems now that I'm looking I'm finding a few truncated stderr.txt. Time to go back to the Commode build. No problem, the .exe is still in my setiathome.berkeley.edu folder, I'll just change the names in my app_info file back before I get any of those Instant Invalids.
Oh, well...

Heh, I thought "truncation immunity by HDD" just seemed too easy. ;^) At least Jason's commode build appears to eliminate them for the NVIDIA GPUs, but that still doesn't help with CPU tasks or the ATI GPUs. We still need the validator fix to actually eliminate the Invalid problem. I haven't had any Invalids so far this month, but did pick up 3 truncations overnight: 4250582637, 4250582741, 4250665618.