That's nice. My main machine is completely out of GPU tasks even though the server has seen fit to recently send me 23 CPU APs that I can't use. It continues to send CPU tasks even though the GPUs are idle;

Sat Dec 20 18:17:48 2014 | SETI@home | [sched_op] Starting scheduler request
Sat Dec 20 18:17:48 2014 | SETI@home | Sending scheduler request: To fetch work.
Sat Dec 20 18:17:48 2014 | SETI@home | Requesting new tasks for CPU and ATI
Sat Dec 20 18:17:48 2014 | SETI@home | [sched_op] CPU work request: 417213.09 seconds; 0.00 devices
Sat Dec 20 18:17:48 2014 | SETI@home | [sched_op] ATI work request: 2604960.00 seconds; 3.00 devices
Sat Dec 20 18:17:50 2014 | SETI@home | Scheduler request completed: got 1 new tasks
Sat Dec 20 18:17:50 2014 | SETI@home | [sched_op] estimated total CPU task duration: 39576 seconds
Sat Dec 20 18:17:50 2014 | SETI@home | [sched_op] estimated total ATI task duration: 0 seconds

I suppose the only alternative is to have the server send them back as GPU tasks and watch it keep sending CPU tasks that aren't needed. Seems if it can't send CPU tasks it will send Nothing.

BTW, the oldest AP file finished and those 3 splitters immediately jumped onto 03se14ad. Now there are 4 splitters working 03se14ad with (7) completed and "Current result creation rate: 0.5886/sec" showing...

There's still something not right with the AP part of SETI.

Lets blame it on Bruno's replacement.

---

Maybe we again need that old program we all used to use - I can't remember the name - that would change WUs from CPU to GPU (and vice versa).

---

There's still something not right with the AP part of SETI.

Take a look at the weekly MB Ready-to-send & Result creation rate graphs and you'll see that the MB splitters have been hampered in their output for the last couple of days.
It used to be the splitters would run at their maximum rate, pump out the work till the ready-to-send buffer had reached it's high water mark, then shut down. Lately the maximum rate has been less than it was & the splitters rarely shut down at all now.


Multiple splitters on the one file was occurring before the AP database issues, but previously it was only a couple of splitters on the one file.
With MB, that still occurs but now we have up to 4 splitters at a time on the AP files. I suspect that having more than one splitter trying to work on one file is resulting in Input/Output contention & hence bogging down the output of the splitters. The more splitters on the one file, the greater the contention & slowdown.

---

Grant
Darwin NT

All i know is i still have not got even 1 Freaking GPU unit since they came back online and i am now getting realy peed off with the b/s excuses .

It's a vlar storm
It's to many splitters on one tape
It's this it's that b/s b/s b/s

There is a major problem so put the dam project down fix it before coming back online

Oh it's now to close to christmas will be the next freaking excuse

1 freaking month and still no joy

And what do is see on the server page the Astropulse science database server is disabled
but the splitter are are not WTF

---

Sten you have to understand Glenn and the fact he is upside down.

---

stern i have not got any AP GPU not one since 31 of the 10 not one AP on the GPU i am not talking about MB twit

try looking at the right stats http://setiathome.berkeley.edu/results.php?userid=8889212&offset=40&show_names=0&state=4&appid=20

---

I'm not the one whom comes here only a few hours after the project is up and whinge about not getting work . Yes i have blown a gasket but it has taken a few day for me to blow it .

I've been patient but now i'm just freaking peed right off . So i have now aborted all the CPU AP's resfet setting to only get GPU AP's so until i start getting them i won't do any other and just start shutting the machine down at the end of the day and start saving money by using less power F it

Untill i start getting GPU AP's i will consider the project still stuffed

---

stern i have not got any AP GPU not one since 31 of the 10 not one AP on the GPU i am not talking about MB twit

try looking at the right stats http://setiathome.berkeley.edu/results.php?userid=8889212&offset=40&show_names=0&state=4&appid=20

Dude, you've been sent 28 APs and then aborted them. Don't do that! Since you have so few tasks on that machine, just set your preferences for GPU APs and hit the reset button. They will be sent back as GPU APs. Once you abort them they are Gone. Just make sure to hit the Update button after changing the preferences so the server will see you want GPU APs.

As I have said before, the Server will try to fill your AP CPU Cache First, then it will worry about sending the GPU tasks. You can try to lower your cache setting so there are fewer CPU tasks to fill, but, from my experience the server knows that trick and still wants to send you 100 CPU tasks before it worries about GPU tasks.

Good luck.
;-)

Hi Glen,
Its that season of the year again.. When the world and everything in it goes crackers:-/

Have a shot of your favourite tipple, look at the cat sideways and hiss a few times:-) Then the Cat can be confused about the state of things like the rest of us..

Eventually things will get sorted.. Just not sure what year that will be, of if I will still be around to see it:-)

Regards,

---

Cliff,
Been there, Done that, Still no damm T shirt!

Tbar mate i have done that the setting are set to only receive GPU AP's

I have aborted those units as one last chance to see what will happen . That way there should be no limits as i have now only got 4 units going on the CPU NO gpu units so the GPU's are just sitting there doing sweet f all

Once those units finish i will reset the project and if i still do not receive any units then F it i will consider the project is still stuffed

Sorry Tbar not peed off with you i know your only trying to help . But the other twit whom whinges to much to then say something to me because after 5 days i whinge F you

---

As I have said before, the Server will try to fill your AP CPU Cache First, then it will worry about sending the GPU tasks. You can try to lower your cache setting so there are fewer CPU tasks to fill, but, from my experience the server knows that trick and still wants to send you 100 CPU tasks before it worries about GPU tasks.

TBar, Here's a couple of work arounds for you to try:

Prior to upping your cache level, set 'Use CPU' to 'No', update Boinc, then up your cache level, Boinc now can't ask for CPU work, so AP can't be sent to the CPU, only GPUs,
you're got four locations/venues available, you can always keep one venue available for doing this, and just move the host to that venue until you're filled up with GPU work.

Or remove the CPU Astropulse app from your app_info, Restart Boinc, Now the scheduler will first predomitly sent VLARs to the CPU, then send any Astropulse and non-VLARs to the GPUs,
you can always put it back in once your GPU cache is full of Astropulse work.

Try Boinc 7.4.36 at least on one of your hosts (at least with the 2nd work around), it has this changeset:

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

client: request work from backed-off resources if doing RPC anyway

It will mean if a task completes (say CPU), the uploading of the CPU result will reset the CPU back-off, and because Boinc is asking for work it'll also ask for work from the other (backed off) resources,
so you'll get more chances of grabbing work.

Claggy

I can't stand on my head and i haven't had a smoke now for over 10 days maybe that's the problem na i'm genuinely getting peed off

---

Hmmm, I'll try it again.

Hitting the reset button without any tasks will accomplish Nothing. The point of hitting the reset is to change 28 CPU tasks to 28 GPU tasks, too late for that now.

The AP server is Fixated on CPU tasks. It Wants to fill your CPU cache. It will not worry about any GPU tasks Until it fills your CPU cache. Your best bet is to let it fill the CPU cache. Right now that is a problem due to low creation rates. So, change your cache setting to about 1 or 2 days and ask for both CPU & GPU APs. It will send the CPU tasks first...Let it. Do not abort them. After it sends the asked for cpu work it will send the GPU work...when it gets around to it. If it balks on the GPU work, Then you can change your preferences to GPU only and hit the reset button. It will then resend the CPU work as GPU work.
Then repeat the above.

I've had the buffer set to 0.5 days now for the last 2 days and i've been letting the buffer run down but i'm getting to peed off so if no joy then i'll just stop for a few weeks maybe then things mite settle .
I had something like 55 units on the cpu when the buffer was set to max on wednesday and i'm only able to do 4 units at a time (overheats) and i just aborted the rest 28 units which would have taken another 3 and a bit days so the buffer should have been at max 2 days ago but still didn't get any thing and i was not allowing V7 MB so why didn't i start getting any .....

After the GPU's just sat there for day doing nothing i did some MB with the buffer set to 0.5 days . BUt now i'm just getting grrrrr

---

As I have said before, the Server will try to fill your AP CPU Cache First, then it will worry about sending the GPU tasks. You can try to lower your cache setting so there are fewer CPU tasks to fill, but, from my experience the server knows that trick and still wants to send you 100 CPU tasks before it worries about GPU tasks.

TBar, Here's a couple of work arounds for you to try:

Prior to upping your cache level, set 'Use CPU' to 'No', update Boinc, then up your cache level, Boinc now can't ask for CPU work, so AP can't be sent to the CPU, only GPUs...

Claggy

I've tried that. The results are I receive very few GPU tasks, not enough to run the machine. I've found the best route is to just let the CPU cache fill, then you receive GPU tasks without any problem. Unfortunately AP tasks are hard to come by at this time, so filling the cache is a problem. In fact, it looks as though all APs have dried up at present. Hopefully we'll be able to fill the caches soon.

I noticed this morning the Astropulse science database server was disabled maybe it's crashed again if no body else is getting them .

GGGGGGGGGGrrrrrrrrrrrrrrrr

oh well guess it's time to just leave the project till after new years and get off my bum and do some of the things i've been wishing to try with this new system like trying to get the Mac Vm working like i had with the Intel Quaddy or hit the torrent sites and catch up on some of the shows i've missed .

Not going to let it get me down so just let it finish what i got reset project then set tings to no new tasks till after New year some time .

But thanks for trying Tbar have a good X-mas everyone if i don't see ya before new years .

---

stop smoking that crap you're smoking, it's not good for you.

Not true

---

i haven't had a smoke now for over 10 days

I'm sorry.

---

stop smoking that crap you're smoking, it's not good for you.

Not true

++1

---

"Sour Grapes make a bitter Whine." <(0)>