So why has my main computer struggled all day and last night to get work when the server status page shows over 300,000 are available? Scanning the top computer list, it's a hit and miss as to who has work. Some machines are empty, others have hundreds.

What's the deal? I'm out of GPU work and would like someone to kick the server and wake it up.

I am having no problems getting MB work. MY machines that do MB are bouncing off their limits actually. Getting new work each time they upload completed work.

---

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

I am having the same problem. One machine is empty and the other have MB and astropulse.

---

I am having no problems getting MB work. MY machines that do MB are bouncing off their limits actually. Getting new work each time they upload completed work.

Same here

---

I am having no problems getting MB work. MY machines that do MB are bouncing off their limits actually. Getting new work each time they upload completed work.

Try letting one run out of GPU tasks and see what happens. 2 of my machines are not having any trouble because they didn't run out of GPU tasks. The one that did run out now can't receive any GPU work because the server stops trying to send it GPU work after a couple tries. You can get all the CPU work you can handle, the Server is set to send CPU over GPU work. It will send work that could go to the GPUs to the CPUs instead. One request netted 17 tasks that could have gone to the GPUs, but the server sent them to the CPUs instead even though the GPUs were empty.

The Perfect Storm comes to mind...

The main problem appears to be once you run out of GPU tasks, because there are so few GPU tasks, the server will stop trying to send GPU tasks before a successful attempt is made. Part of the problem is the server is set to Fill the CPU cache First even if the GPU cache is empty.

I am having no problems getting MB work. MY machines that do MB are bouncing off their limits actually. Getting new work each time they upload completed work.

Try letting one run out of GPU tasks and see what happens. 2 of my machines are not having any trouble because they didn't run out of GPU tasks. The one that did run out now can't receive any GPU work because the server stops trying to send it GPU work after a couple tries. You can get all the CPU work you can handle, the Server is set to send CPU over GPU work. It will send work that could go to the GPUs to the CPUs instead. One request netted 17 tasks that could have gone to the GPUs, but the server sent them to the CPUs instead even though the GPUs were empty.

The Perfect Storm comes to mind...

When I was testing that in your thread about AP work fetch issues I didn't have that occur. I was getting GPU & CPU work intermixed.

---

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

I am having no problems getting MB work. MY machines that do MB are bouncing off their limits actually. Getting new work each time they upload completed work.

Try letting one run out of GPU tasks and see what happens. 2 of my machines are not having any trouble because they didn't run out of GPU tasks. The one that did run out now can't receive any GPU work because the server stops trying to send it GPU work after a couple tries. You can get all the CPU work you can handle, the Server is set to send CPU over GPU work. It will send work that could go to the GPUs to the CPUs instead. One request netted 17 tasks that could have gone to the GPUs, but the server sent them to the CPUs instead even though the GPUs were empty.

The Perfect Storm comes to mind...

When I was testing that in your thread about AP work fetch issues I didn't have that occur. I was getting GPU & CPU work intermixed.

Gee, so is that why you went silent when I told you to increase the FLOP setting? Every machine I have will try to fill the CPU cache first. Others experience the Same affect. Why are yours different? I just woke up to find my Win 8 machine had downloaded 17 CPU APs and Zero GPU APs even though it was set for both. Why do you suppose that happened? Of course, I had the server send them back as GPU tasks 'cause I have dozens of CPU VLARs.

12/18/2014 13:02:51 | SETI@home | Sending scheduler request: To fetch work.
12/18/2014 13:02:51 | SETI@home | Requesting new tasks for ATI
12/18/2014 13:02:54 | SETI@home | Scheduler request completed: got 17 new tasks
12/18/2014 13:02:54 | SETI@home | Resent lost task ap_03jn14ae_B2_P1_00431_20141217_00438.wu_0
...

Why do you suppose the Server is sending all those CPU APs when there are a couple Hundred Thousand CPU VLARs waiting to be sent?

This machine has been out of GPU work for Hours, http://setiathome.berkeley.edu/results.php?hostid=6796479
I did manage to net 1 GPU AP when asking for both CPU & GPU work with maxed out cache settings. I have a few more local CPU MBs that can be exchanged for GPU tasks, but right now the machine has a 40 minute GPU fetch deferral. So, it won't even try to send GPU tasks for another 40 minutes...

[quote]When I was testing that in your thread about AP work fetch issues I didn't have that occur. I was getting GPU & CPU work intermixed.

Gee, so is that why you went silent when I told you to increase the FLOP setting? Every machine I have will try to fill the CPU cache first. Others experience the Same affect. Why are yours different? I just woke up to find my Win 8 machine had downloaded 17 CPU APs and Zero GPU APs even though it was set for both. Why do you suppose that happened? Of course, I had the server send them back as GPU tasks 'cause I have dozens of CPU VLARs.

Well I was ready to do more testing with the flop values from your system. However I found it rather hard to do any AP work fetch testing once the servers went to bits a few days later. When the servers return to some sort of normal working state testing can resume. Probably after the holidays when things are less busy for me again.

Prior to that I did test MB work fetch.

---

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

[quote]When I was testing that in your thread about AP work fetch issues I didn't have that occur. I was getting GPU & CPU work intermixed.

Gee, so is that why you went silent when I told you to increase the FLOP setting? Every machine I have will try to fill the CPU cache first. Others experience the Same affect. Why are yours different? I just woke up to find my Win 8 machine had downloaded 17 CPU APs and Zero GPU APs even though it was set for both. Why do you suppose that happened? Of course, I had the server send them back as GPU tasks 'cause I have dozens of CPU VLARs.

Well I was ready to do more testing with the flop values from your system. However I found it rather hard to do any AP work fetch testing once the servers went to bits a few days later. When the servers return to some sort of normal working state testing can resume. Probably after the holidays when things are less busy for me again.

Prior to that I did test MB work fetch.

Can you give any suggestions for this machine that has been out of GPU tasks for Hours?
http://setiathome.berkeley.edu/results.php?hostid=6796479
It is showing a Scheduling priority of -1.00 and an AMD work fetch deferral interval of 40 minutes. It has Zero GPU tasks, except 1 former CPU task, and now has a 10 day cache setting.

If you have plenty of CPU cache, you could set your Seti preferences to only accept GPU work. Then do updates every 5 min or so until you start geting some GPU work. Once you build up enough GPU work you can turn the CPU work fetch back on.

I would also turn down you 10 day cache down to a reasonable level as this really doesn't actually help anything since we are all limited to 100 WU per CPU/GPU.

After hours of trying it finally received 35 GPU MBs. I had the cache at 2 days with it asking for All types of work. It already had well over 2 days of CPU VLAR tasks.

Thu Dec 18 17:29:54 2014 | SETI@home | Requesting new tasks for ATI
Thu Dec 18 17:29:54 2014 | SETI@home | [sched_op] CPU work request: 0.00 seconds; 0.00 devices
Thu Dec 18 17:29:54 2014 | SETI@home | [sched_op] ATI work request: 531032.55 seconds; 2.50 devices
Thu Dec 18 17:29:55 2014 | SETI@home | Scheduler request completed: got 35 new tasks
Thu Dec 18 17:29:55 2014 | SETI@home | [sched_op] Server version 705
Thu Dec 18 17:29:55 2014 | SETI@home | Project requested delay of 303 seconds
Thu Dec 18 17:29:55 2014 | SETI@home | [sched_op] estimated total CPU task duration: 0 seconds
Thu Dec 18 17:29:55 2014 | SETI@home | [sched_op] estimated total ATI task duration: 87432 seconds

What a pain. It sure would be nice if the AP Splitters could do better than, Current result creation rate = 0/sec
So low it doesn't even register.

I gave up long time ago and have been testing the APs on Beta..

What's the deal? I'm out of GPU work and would like someone to kick the server and wake it up.

Same here, Berkeley's knackered. This is why we need an alternative project that searches for different kinds of ET signals. Maybe then Berkeley might pick its game up.

cheers

---

I have six low power machines, with equally low power GPU's, and I do not have problems, all my machines have CPU work for my 3 day cache and my GPU's all have 100 wu's

For people like me the project appears to be working exactly as it should.

I currently have a few AP's as well.

I don't run out of GPU work during the outage so don't encounter any problems.

Remember we recently ran out of work to process, so perhaps things have been "slowed down" a bit so we don't totally run out before the next batch arrives.

Also as far as I am aware Nitpckr is still not running so I don't see there is any hurry.

Just my 2 cents.

---

What a pain. It sure would be nice if the AP Splitters could do better than, Current result creation rate = 0/sec
So low it doesn't even register.

I think we know that particular counter is still hooked up to the AP v6 statistics. So it's accurate, but unhelpful.

The cricket graphs suggest a real, significant, amount of data is making it out through the door.

What a pain. It sure would be nice if the AP Splitters could do better than, Current result creation rate = 0/sec
So low it doesn't even register.

I think we know that particular counter is still hooked up to the AP v6 statistics. So it's accurate, but unhelpful.

The cricket graphs suggest a real, significant, amount of data is making it out through the door.

Great, so why aren't my machines receiving more than a few a day? Back after the switch to the COLO I could fill both caches in around a couple hours. I would receive 8 every five minutes or around ~100 an hour. Before the AP Database explosion I could fill a 400 AP cache in a couple days. Back then the creation rate was around 3-5/sec. Here is the numbers for the same Machine;
AstroPulse v7 (anonymous platform, ATI GPU) Number of tasks today: 20
20 is a long way from 200. Imagine the old 100 per hour. That host can complete 150 a day. Even while completing 150 a day, the 400 AP cache would fill in about two days.

My other machines show similar numbers.
Something is seriously wrong with the AP Creation rate.
Considering there are Years of AP data available and just a few weeks of MB data,
You would think SETI would be pushing the APs.
Looking at the AP total channels to do, it doesn't look as though much progress is being made,
total channels to do: 2311
Keep an Eye on that number, I have been.