Uh, oh...
I see the SSP has not updated in over an hour, and the loading of stats seems to be crawling again.

I am going to assume that boinc.berkeley.edu suddenly being offline as well is unrelated.

And....my bad, folks.
I just recovered my daily driver after being down for several days, and the clock somehow got off by an hour.
Might be a false alarm, although for some reason, I seem to be losing cache.

---

"Time is simply the mechanism that keeps everything from happening all at once."

I am going to assume that boinc.berkeley.edu suddenly being offline as well is unrelated.

It isn't down for me at this time, but I have seen database errors, and pages claiming the whole thing was down. Then 2 seconds later it would load normally. Something or someone is hitting the domain hard, has been doing that for a couple of days now.

---

I am going to assume that boinc.berkeley.edu suddenly being offline as well is unrelated.

It isn't down for me at this time, but I have seen database errors, and pages claiming the whole thing was down. Then 2 seconds later it would load normally. Something or someone is hitting the domain hard, has been doing that for a couple of days now.

I've seen the site hiccup before. It had been down for a while & the eternal site places were indicating it was down as well.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

http://setiathome.berkeley.edu/gpu_list.php

this is what I got

The following lists show the most productive GPU models on different platforms. Relative speeds, measured by average elapsed time of tasks, are shown in parentheses. Notice: Trying to get property of non-object in /disks/carolyn/b/home/boincadm/projects/sah/html/user/gpu_list.php on line 208
NVIDIA
Notice: Trying to get property of non-object in /disks/carolyn/b/home/boincadm/projects/sah/html/user/gpu_list.php on line 175 No GPU tasks reported Notice: Trying to get property of non-object in /disks/carolyn/b/home/boincadm/projects/sah/html/user/gpu_list.php on line 209
ATI/AMD
Notice: Trying to get property of non-object in /disks/carolyn/b/home/boincadm/projects/sah/html/user/gpu_list.php on line 175 No GPU tasks reported Notice: Trying to get property of non-object in /disks/carolyn/b/home/boincadm/projects/sah/html/user/gpu_list.php on line 210
Intel
Notice: Trying to get property of non-object in /disks/carolyn/b/home/boincadm/projects/sah/html/user/gpu_list.php on line 175 No GPU tasks reported Notice: Trying to get property of non-object in /disks/carolyn/b/home/boincadm/projects/sah/html/user/gpu_list.php on line 211

Generated --- 

---

To overcome Heisenbergs:
"You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones

http://setiathome.berkeley.edu/gpu_list.php

this is what I got

The following lists show the most productive GPU models on different platforms. Relative speeds, measured by average elapsed time of tasks, are shown in parentheses. Notice: Trying to get property of non-object in /disks/carolyn/b/home/boincadm/projects/sah/html/user/gpu_list.php on line 208
NVIDIA
Notice: Trying to get property of non-object in /disks/carolyn/b/home/boincadm/projects/sah/html/user/gpu_list.php on line 175 No GPU tasks reported Notice: Trying to get property of non-object in /disks/carolyn/b/home/boincadm/projects/sah/html/user/gpu_list.php on line 209
ATI/AMD
Notice: Trying to get property of non-object in /disks/carolyn/b/home/boincadm/projects/sah/html/user/gpu_list.php on line 175 No GPU tasks reported Notice: Trying to get property of non-object in /disks/carolyn/b/home/boincadm/projects/sah/html/user/gpu_list.php on line 210
Intel
Notice: Trying to get property of non-object in /disks/carolyn/b/home/boincadm/projects/sah/html/user/gpu_list.php on line 175 No GPU tasks reported Notice: Trying to get property of non-object in /disks/carolyn/b/home/boincadm/projects/sah/html/user/gpu_list.php on line 211

Generated --- 

And the noticed at the top:
Notice: unserialize(): Error at offset 24625 of 45995 bytes in /disks/carolyn/b/home/boincadm/projects/sah/html/user/gpu_list.php on line 200

A PHP error normally indicating something is corrupt.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

Uh, oh...
I see the SSP has not updated in over an hour, and the loading of stats seems to be crawling again.

I am going to assume that boinc.berkeley.edu suddenly being offline as well is unrelated.

And....my bad, folks.
I just recovered my daily driver after being down for several days, and the clock somehow got off by an hour.
Might be a false alarm, although for some reason, I seem to be losing cache.

I noticed that too. Clicked the update button a couple time cycles. A nice number of wu's feel from the tree.

---

How the hell can this validate?

Stderr output
<core_client_version>7.4.42</core_client_version>
<![CDATA[
<stderr_txt>

</stderr_txt>
]]>

http://setiathome.berkeley.edu/workunit.php?wuid=1819553789

I have more than a few tasks doing this

And I haven't figured out yet why I'm shooting blanks on MB GPU tasks :(([/url]

I think I see a pattern to this now, and only seems to affect MB.

- new task starts
- pending upload waiting
- cpu hits load limit (90%)
- cpu shuts tasks down until upload is done
- then everything fires up again

I'm seeing this over and over if 2 things are happening at once.

2015-07-07 5:09:20 AM | SETI@home | Starting task 31dc12ad.30837.459788.438086664208.12.109_2
2015-07-07 5:09:21 AM | | Suspending computation - CPU is busy
2015-07-07 5:09:22 AM | SETI@home | Started upload of 13ja15ab.7158.1193235.438086664198.12.242_2_0
2015-07-07 5:09:24 AM | SETI@home | Finished upload of 13ja15ab.7158.1193235.438086664198.12.242_2_0
2015-07-07 5:09:31 AM | | Resuming computation

I have removed the 'suspend' when busy setting, and freed a core when running MB, and it's still complaining .... GRRRRR

Funny thing is my SLOW AMD is just fine, it's my i5 that is doing it .. GRRRR

---

I'm wondering ... I had report tasks immediately set on my i5. (I changed it)

So does BOINC think the slot is empty after it is uploaded and just assume it has free access to the slot files to overwrite? Thus blanking them out?

---

I'm wondering ... I had report tasks immediately set on my i5. (I changed it)

So does BOINC think the slot is empty after it is uploaded and just assume it has free access to the slot files to overwrite? Thus blanking them out?

No. We went into this in some detail (Ivan will confirm) while we were fixing LHC's CMS-dev application and the problems it was causing at other projects. Enable the <slot_debug> logging flag, and you will see that the slots are cleansed both when the old task finishes, and again before the new task starts. The only problem would be when stderr.txt grows to be more than 4 GB in size. If that happens, upgrade to BOINC v7.6.2, which can handle it.

Edit, and before any of that happens, stderr.txt for the old task is read back from disk and copied into the statefile structure in memory. From there, it is written out peridically into client_state.xml, just in case BOINC is restarted before the report is accepted - that way, there's a persistent record so the report can be retried after maintenance is complete.

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.

---

"Time is simply the mechanism that keeps everything from happening all at once."

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.