In all of my venues, I have the three GPU types unchecked. Neither of my rigs have usable GPUs anyway.

I didn't change anything on my end, and the only difference I see now is server version changed from 703 to 705. My other host has gotten work since after the change to 705.

I did some testing on one of my machines with two old versions.
6.2.19 - Requested work & was not given any. Just as you are seeing.
6.6.33 - Requested work & was given work.

So you are not crazy, well not completely at least... The server code changes have borked you. Defiantly time to bring it to the attention of the BOINC devs, or switch to a version < 6 years old.

I was a bit bored today so I gave some other versions a try.
6.4.5 - Requested work & was not given any.
6.6.0 - Requested work & was not given any.

Looks like there is a specific build of 6.6.x that is the dividing live between working and not. The 6.6.0 version is listed a a development build, but I wanted to try it anyway. To see if all 6.6.x build worked.

IIRC wasn't GPU processing support added in a 6.6.x build? Given they were messing around with the GPU scheduling bits of the server code perhaps the first version to support GPUs will get work when requested.

---

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

Now for a change of pace.. it looks like the candlelight vigil for the 30 and 31 tapes might come to an end soon. I wonder if that is deliberate. At least one or two of those tapes will get split up, maybe not all of them, but.. there is hope for them after all!

I've been watching that all morning....wondering what will start splitting next or if AP will jump in again before the splitters get there.

When I looked this morning we were at ~130 channels to do. Now 6 hours later we are at 116. If that is a consistent rate we have about 2 more days before those are done.

---

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

David has done a checkout to hopefully fix this:

http://boinc.berkeley.edu/gitweb/?p=boinc-v2.git;a=commit;h=60a35821517fb686087aa56bd6dc86134d313a85

scheduler: if client reports zero elapsed time, set ET to CPU time

Just need a new scheduler now.

Claggy

In all of my venues, I have the three GPU types unchecked. Neither of my rigs have usable GPUs anyway.

I didn't change anything on my end, and the only difference I see now is server version changed from 703 to 705. My other host has gotten work since after the change to 705.

I did some testing on one of my machines with two old versions.
6.2.19 - Requested work & was not given any. Just as you are seeing.
6.6.33 - Requested work & was given work.

So you are not crazy, well not completely at least... The server code changes have borked you. Defiantly time to bring it to the attention of the BOINC devs, or switch to a version < 6 years old.

I was a bit bored today so I gave some other versions a try.
6.4.5 - Requested work & was not given any.
6.6.0 - Requested work & was not given any.

Looks like there is a specific build of 6.6.x that is the dividing live between working and not. The 6.6.0 version is listed a a development build, but I wanted to try it anyway. To see if all 6.6.x build worked.

IIRC wasn't GPU processing support added in a 6.6.x build? Given they were messing around with the GPU scheduling bits of the server code perhaps the first version to support GPUs will get work when requested.

The (very ancient) CUDA FAQs say v6.4.4 was the minimum requirement (I'd remembered v6.4.5), but we went through some rapid changes as it settled down.

The powers-that-be are sniffing around, and reckon they've fixed part of the problem, but not that bit yet.

Now for a change of pace.. it looks like the candlelight vigil for the 30 and 31 tapes might come to an end soon. I wonder if that is deliberate. At least one or two of those tapes will get split up, maybe not all of them, but.. there is hope for them after all!

I've been watching that all morning....wondering what will start splitting next or if AP will jump in again before the splitters get there.

When I looked this morning we were at ~130 channels to do. Now 6 hours later we are at 116. If that is a consistent rate we have about 2 more days before those are done.

And it looks like 29no13aa has been resumed. There's hope.. let's see how many of those 30 and 31 tapes can get started before more tapes get loaded.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

Now for a change of pace.. it looks like the candlelight vigil for the 30 and 31 tapes might come to an end soon. I wonder if that is deliberate. At least one or two of those tapes will get split up, maybe not all of them, but.. there is hope for them after all!

I've been watching that all morning....wondering what will start splitting next or if AP will jump in again before the splitters get there.

When I looked this morning we were at ~130 channels to do. Now 6 hours later we are at 116. If that is a consistent rate we have about 2 more days before those are done.

And it looks like 29no13aa has been resumed. There's hope.. let's see how many of those 30 and 31 tapes can get started before more tapes get loaded.

There is another spike on the inbound data transfer. So they might be loading up a second round of data sets. I think last time they did that we had a ton of them to go through.
Hopefully we can manage to burn off some of the high numbered sets before the new data gets loaded in for splitting.

---

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

David has done a checkout to hopefully fix this:

http://boinc.berkeley.edu/gitweb/?p=boinc-v2.git;a=commit;h=60a35821517fb686087aa56bd6dc86134d313a85

scheduler: if client reports zero elapsed time, set ET to CPU time

Just need a new scheduler now.

Claggy

Well that bit of code certainly improved ;D

If that does the trick, fine.
Personally I doubt it.

it's like watching the ripples on the water and trying to make out what shape the object was that was dropped in... you'd have to find the impact location and dive for it.
Unfortunately I have no time whatsoever to spemd on this atm. If such a thing was possible I'd be in negative time.

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

David has done a checkout to hopefully fix this:

http://boinc.berkeley.edu/gitweb/?p=boinc-v2.git;a=commit;h=60a35821517fb686087aa56bd6dc86134d313a85

scheduler: if client reports zero elapsed time, set ET to CPU time

Just need a new scheduler now.

Claggy

Well that bit of code certainly improved ;D

If that does the trick, fine.
Personally I doubt it.

it's like watching the ripples on the water and trying to make out what shape the object was that was dropped in... you'd have to find the impact location and dive for it.
Unfortunately I have no time whatsoever to spemd on this atm. If such a thing was possible I'd be in negative time.

We might have a solution:

There was a bug in the new server code
that prevented it from sending jobs to pre-6.7 clients.
I checked in a fix (4 lines in sched/sched_types.h).

Jeff, can you deploy this in beta and public?

Thanks -- David

Could those affected keep an eye on this, and let us know what transpires - pro or anti? Thanks.

And AP work is being split once again.

---

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

We might have a solution:

There was a bug in the new server code that prevented it from sending jobs to pre-6.7 clients. I checked in a fix (4 lines in sched/sched_types.h). Jeff, can you deploy this in beta and public?
Thanks -- David

Could those affected keep an eye on this, and let us know what transpires - pro or anti? Thanks.

Will do. So far there's no change, but I don't know when it will be deployed.

And AP work is being split once again.

More importantly.. two low-numbered tapes got loaded and 29no13aa that WAS being split some more got interrupted and the splitters appear to have jumped to the new tapes. So far, just two tapes got loaded.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

We might have a solution:

There was a bug in the new server code that prevented it from sending jobs to pre-6.7 clients. I checked in a fix (4 lines in sched/sched_types.h). Jeff, can you deploy this in beta and public?
Thanks -- David

Could those affected keep an eye on this, and let us know what transpires - pro or anti? Thanks.

Will do. So far there's no change, but I don't know when it will be deployed.

And AP work is being split once again.

More importantly.. two low-numbered tapes got loaded and 29no13aa that WAS being split some more got interrupted and the splitters appear to have jumped to the new tapes. So far, just two tapes got loaded.

Yeah at the rate it is going 29no13aa will be done sometime in November,

So far 1 AP channel ended in error. Which is much better than the last set of data. They might be loading in less at a time now to see how the AP splitters handle it, or it could be a different reason all together.

---

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

Has anyone noticed the server is sending out CPU tasks even if your GPUs don't have any work? All 3 of my Hosts are receiving CPU work even though they are not needed. I have a Mac whose 3 GPUs are going idle while the server sends it CPU work. If I change the preferences to GPU only, the server doesn't send any work :-(

Has anyone noticed the server is sending out CPU tasks even if your GPUs don't have any work? All 3 of my Hosts are receiving CPU work even though they are not needed. I have a Mac whose 3 GPUs are going idle while the server sends it CPU work. If I change the preferences to GPU only, the server doesn't send any work :-(

On my HTPC I am getting.
SETI@home Tasks for AMD/ATI GPU are available, but your preferences are set to not accept them
SETI@home This computer has reached a limit on tasks in progress
Despite the fact it is in the only venue that allows ATI work. It has 7 GPU & 89 CPU tasks.
I figure they might still be playing around with the schedule stuff.

---

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

And AP work is being split once again.

And not much.

---

Has anyone noticed the server is sending out CPU tasks even if your GPUs don't have any work? All 3 of my Hosts are receiving CPU work even though they are not needed. I have a Mac whose 3 GPUs are going idle while the server sends it CPU work. If I change the preferences to GPU only, the server doesn't send any work :-(

On my HTPC I am getting.
SETI@home Tasks for AMD/ATI GPU are available, but your preferences are set to not accept them
SETI@home This computer has reached a limit on tasks in progress
Despite the fact it is in the only venue that allows ATI work. It has 7 GPU & 89 CPU tasks.
I figure they might still be playing around with the schedule stuff.

All CPU tasks;
http://setiathome.berkeley.edu/results.php?hostid=7258715
http://setiathome.berkeley.edu/results.php?hostid=6796475&offset=0&show_names=0&state=0&appid=12
http://setiathome.berkeley.edu/results.php?hostid=6796479

I had to Force the Mac to resend CPU task as GPU tasks or else it would be GPU Idle. Now that it has downloaded a few more CPU tasks, it has Stopped downloading Any Tasks. Soon the GPUs will be Idle again.

Has anyone noticed the server is sending out CPU tasks even if your GPUs don't have any work? All 3 of my Hosts are receiving CPU work even though they are not needed. I have a Mac whose 3 GPUs are going idle while the server sends it CPU work. If I change the preferences to GPU only, the server doesn't send any work :-(

What I'm seeing over the last several days is that sometimes a work fetch for both CPU and GPU will only return one or more VLARs for the CPU, but nothing for the GPU. However, usually the next request will fill up the GPU queue, too. It seems as if when the scheduler only finds VLARs at the top of its RTS buffer, it sometimes doesn't dig very deep to find non-VLARs for the GPU if it's pressed for time. I haven't had any hosts stop getting GPU tasks altogether.

Edit: Ah, I see you're talking about AP-only hosts. Never mind! AP tasks are rare in my world.

This is what my Mac is getting right now,

Wed Sep  3 21:54:52 2014 | SETI@home | Sending scheduler request: To fetch work.
Wed Sep  3 21:54:52 2014 | SETI@home | Reporting 1 completed tasks
Wed Sep  3 21:54:52 2014 | SETI@home | Requesting new tasks for CPU and ATI
Wed Sep  3 21:54:53 2014 | SETI@home | Scheduler request completed: got 0 new tasks
Wed Sep  3 21:54:53 2014 | SETI@home | No tasks sent
Wed Sep  3 21:54:53 2014 | SETI@home | No tasks are available for AstroPulse v6
Wed Sep  3 21:59:59 2014 | SETI@home | Sending scheduler request: To fetch work.
Wed Sep  3 21:59:59 2014 | SETI@home | Requesting new tasks for CPU and ATI
Wed Sep  3 22:00:00 2014 | SETI@home | Scheduler request completed: got 0 new tasks
Wed Sep  3 22:00:00 2014 | SETI@home | No tasks sent
Wed Sep  3 22:00:00 2014 | SETI@home | No tasks are available for AstroPulse v6
Wed Sep  3 22:07:06 2014 | SETI@home Beta Test | Sending scheduler request: To fetch work.
Wed Sep  3 22:07:06 2014 | SETI@home Beta Test | Requesting new tasks for ATI
Wed Sep  3 22:07:08 2014 | SETI@home Beta Test | Scheduler request completed: got 0 new tasks
Wed Sep  3 22:08:19 2014 | SETI@home | Sending scheduler request: To fetch work.
Wed Sep  3 22:08:19 2014 | SETI@home | Requesting new tasks for CPU and ATI
Wed Sep  3 22:08:20 2014 | SETI@home | Scheduler request completed: got 0 new tasks
Wed Sep  3 22:08:20 2014 | SETI@home | No tasks sent
Wed Sep  3 22:08:20 2014 | SETI@home | No tasks are available for AstroPulse v6
Wed Sep  3 22:13:49 2014 | SETI@home | update requested by user
Wed Sep  3 22:13:51 2014 | SETI@home | Sending scheduler request: Requested by user.
Wed Sep  3 22:13:51 2014 | SETI@home | Requesting new tasks for CPU and ATI
Wed Sep  3 22:13:52 2014 | SETI@home | Scheduler request completed: got 0 new tasks
Wed Sep  3 22:13:52 2014 | SETI@home | No tasks sent
Wed Sep  3 22:13:52 2014 | SETI@home | No tasks are available for AstroPulse v6

It has 4 GPU tasks left. I'll bet if I force those new CPU tasks to GPU tasks it will start downloading CPU tasks again...even though it needs GPU tasks instead.

Well, so far I've only gotten 1 AP task in the 3+ hours since they started loading new tapes, and it went to a GPU on my xw9400.

Has anyone noticed the server is sending out CPU tasks even if your GPUs don't have any work? All 3 of my Hosts are receiving CPU work even though they are not needed. I have a Mac whose 3 GPUs are going idle while the server sends it CPU work. If I change the preferences to GPU only, the server doesn't send any work :-(

What I'm seeing over the last several days is that sometimes a work fetch for both CPU and GPU will only return one or more VLARs for the CPU, but nothing for the GPU. However, usually the next request will fill up the GPU queue, too. It seems as if when the scheduler only finds VLARs at the top of its RTS buffer, it sometimes doesn't dig very deep to find non-VLARs for the GPU if it's pressed for time. I haven't had any hosts stop getting GPU tasks altogether.

Edit: Ah, I see you're talking about AP-only hosts. Never mind! AP tasks are rare in my world.

If you had a Mac ALL you would run on the GPUs are APs since there isn't an ATI MB App. It's down to 2 GPU tasks while it has downloaded 9 more CPU tasks. The GPUs are about to go Idle again while it keeps getting CPU work.

If you had a Mac ALL you would run on the GPUs are APs since there isn't an ATI MB App. It's down to 2 GPU tasks while it has downloaded 9 more CPU tasks. The GPUs are about to go Idle again while it keeps getting CPU work.

Yeah, I don't have a MAC and only one of my machines has an ATI card (an old 5450).

I just noticed 2 more APs downloaded, this time to my T7400, and both went to the GPU queue, so whatever problem you're experiencing, it isn't hitting here. Perhaps another MAC / ATI user will have to chime in. Certainly the AP RTS buffer is still running on empty, and the new tapes are throwing errors just like the last batch, so that isn't helping.