Need to say last few dozens of posts made this thread absolutely unworthy for monitoring AP7 issues. So if someone has something to say (and wanna be heared, of course) please start new thread or post in APv7 issues & errors one.

Regarding new thread topic (BOINC fetch issues) well, I did noticed too that often BOINC client asking for both CPU and GPU work but almost (by my impression) never gets work for both types in single request (though asked for both).

But usually I trying to do separate CPU MB and GPU AP queues filling by micromanagement so did not have many or consistent enough observation on this point.

26-Oct-2014 22:16:29 [SETI@home] Scheduler request completed: got 2 new tasks
26-Oct-2014 22:16:29 [SETI@home] [sched_op] estimated total CPU task duration: 7843 seconds
26-Oct-2014 22:16:29 [SETI@home] [sched_op] estimated total Intel GPU task duration: 10242 seconds
26-Oct-2014 22:16:31 [SETI@home] Started download of 16jn14aa.25013.686396.438086664199.12.195.vlar
26-Oct-2014 22:16:31 [SETI@home] Started download of ap_30oc11ab_B3_P1_00206_20141026_21229.wu

If you want to find a discussion of AP v7 applications, you'll mostly find it in my installer thread :)

If GPU queue would be filled first You could do project reset and get CPU tasks resent to GPU. Nothing wrong with that and I think some people have done that purposefully.

All you have to do is set your Preferences to GPU only, then do a Project Reset. All the Tasks will be reassigned to the GPU. There are other ways without doing a reset, but, the reset is the easiest. I'm supposing the reset still works that way, I haven't tried it in a while. In about another day my one Host will be very low and I'll give it a try. I'm going to leave the Preferences set for both first, then change it again if they just go to the CPU, as I suppose they will. APs Are Not MBs.

Any one notice APv7s are going much faster than APv6? Since the APs stopped late on the 26th/early 27th I'm down to In progress (186). Over half gone already. I'll take as many Resends as possible no matter where they go. Like I said, I can Compensate...as long as I have something to Compensate with. It would be really nice if all the resends went to the GPUs to begin with, save a little work that way. I count 26 resends since the well went dry, with 2 going to the GPU, http://setiathome.berkeley.edu/results.php?hostid=6796479
Down to 183.

I was just sent another 6 AP resends that all went to the CPUs even though my 3 GPUs are getting really Low.

I'm really starting to like Claggy's old suggestion about the Server sending tasks without any device restrictions. APs are APs, they are the same. There isn't any need to have device restrictions. The Manager should be allowed to just send tasks to the device that needs them. It would make things much less complicated.

Until your GPU cache is full, moderate your cache size until Boinc no longer asks for CPU work, once you have some GPU work then increase it in steps.

Claggy

Until your GPU cache is full, moderate your cache size until Boinc no longer asks for CPU work, once you have some GPU work then increase it in steps.

Claggy

I'm just about out of GPU tasks. Take a Good look at the results page. In a couple hours they will probably all turn into CPU tasks. Shortly thereafter most of them will go back to GPU tasks.

Did anyone ever submit a reasonable reason for not just having Plain APs as you suggested a while back? I can't think of any reason to have device restrictions.

A new High! Last week I thought I had seen something strange when after the Outage the Completed Ready to Reports on my Computer were already showing up on the Results page on the web even though my computer said it hadn't contacted the Mothership in Hours. That was fixed by setting NNT and updating. This week I decided to test the Project reset. All 79 AP tasks were resent to the computer and listed as AstroPulse 701 CPU tasks and the Manager showed 3 running on the CPUs. But the Web said they were ATI tasks! I should have taken a picture. I did the only thing I could, I restarted BOINC. When it came back it listed them All as ATI tasks, running on the GPUs. You can't make this stuff up! I checked the slots and there isn't any indication they had been run on the CPUs. This has to be the strangest thing I've seen to date. Oh well, it's working anyway...

Did anyone ever submit a reasonable reason for not just having Plain APs as you suggested a while back? I can't think of any reason to have device restrictions.

What do you mean??? There is no difference between CPU and GPU AP tasks at all. Not even some scheduler rules as for VLAR MB...

Did anyone ever submit a reasonable reason for not just having Plain APs as you suggested a while back? I can't think of any reason to have device restrictions.

What do you mean??? There is no difference between CPU and GPU AP tasks at all. Not even some scheduler rules as for VLAR MB...

The VLARs are the only problem, since those are kept from the GPUs. What I mean is why do I have AstroPulse v7 Anonymous platform (ATI GPU) And AstroPulse v7 Anonymous platform (CPU). Why not just AstroPulse v7 Anonymous platform. Then the Manager wouldn't have to limit the tasks to certain devices. That way you wouldn't get stuck with 79 CPU tasks that would take over 10 days to complete on the CPUs or only 11 hours to complete on the GPUs. The tasks could be sent to the GPUs or CPUs depending on which device needed them. I'm pretty sure that's what Claggy was suggesting back in one of those old CreditFew threads.

Hmmm, seems I have more CPU resends.

Did anyone ever submit a reasonable reason for not just having Plain APs as you suggested a while back? I can't think of any reason to have device restrictions.

What do you mean??? There is no difference between CPU and GPU AP tasks at all. Not even some scheduler rules as for VLAR MB...

The VLARs are the only problem, since those are kept from the GPUs. What I mean is why do I have AstroPulse v7 Anonymous platform (ATI GPU) And AstroPulse v7 Anonymous platform (CPU). Why not just AstroPulse v7 Anonymous platform. Then the Manager wouldn't have to limit the tasks to certain devices. That way you wouldn't get stuck with 79 CPU tasks that would take over 10 days to complete on the CPUs or only 11 hours to complete on the GPUs. The tasks could be sent to the GPUs or CPUs depending on which device needed them. I'm pretty sure that's what Claggy was suggesting back in one of those old CreditFew threads.

Hmmm, seems I have more CPU resends.

Ah you just want a general pool of tasks on the client end and then let the client process them on the hardware as it sees fit. Other than the issues that the BOINC devs would have to overcome for that to happen, of which I imagine there would be a few, it seems like a logical way to do things. I think several people have suggested BOINC work like this since GPU crunched started. How other projects would handle such a change is really the issue.

---

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

Only APs on my GPU, nothing else. Occasionally vLHC on CPU, but I don't think that could make APs on my GPU run slower, could it?

Chances are not 0, but you can compare the times of when the tasks were running via your stdoutdae.txt.

Heavily blanked tasks run much faster than low blanked.
If you are running 2 instances on your GPU those different blankings also affecting run times.

Thx Hal & Mike, I will keep an eye on this!

---

Did anyone ever submit a reasonable reason for not just having Plain APs as you suggested a while back? I can't think of any reason to have device restrictions.

What do you mean??? There is no difference between CPU and GPU AP tasks at all. Not even some scheduler rules as for VLAR MB...

The VLARs are the only problem, since those are kept from the GPUs. What I mean is why do I have AstroPulse v7 Anonymous platform (ATI GPU) And AstroPulse v7 Anonymous platform (CPU). Why not just AstroPulse v7 Anonymous platform. Then the Manager wouldn't have to limit the tasks to certain devices. That way you wouldn't get stuck with 79 CPU tasks that would take over 10 days to complete on the CPUs or only 11 hours to complete on the GPUs. The tasks could be sent to the GPUs or CPUs depending on which device needed them. I'm pretty sure that's what Claggy was suggesting back in one of those old CreditFew threads.

Hmmm, seems I have more CPU resends.

Ah you just want a general pool of tasks on the client end and then let the client process them on the hardware as it sees fit. Other than the issues that the BOINC devs would have to overcome for that to happen, of which I imagine there would be a few, it seems like a logical way to do things. I think several people have suggested BOINC work like this since GPU crunched started. How other projects would handle such a change is really the issue.

Yes, seems if you could just have a pool of AP tasks that would solve the recently discussed problems. I'm sure there would be others.

Speaking of which, New APs are being Split...just in time. I'm out of GPU tasks, I've already received a few New tasks, and they are All labeled CPU.

Wed Oct 29 13:42:08 2014 | SETI@home | Sending scheduler request: To fetch work.
Wed Oct 29 13:42:08 2014 | SETI@home | Reporting 1 completed tasks
Wed Oct 29 13:42:08 2014 | SETI@home | Requesting new tasks for CPU and ATI
Wed Oct 29 13:42:11 2014 | SETI@home | Scheduler request completed: got 4 new tasks
Wed Oct 29 13:57:37 2014 | SETI@home | Sending scheduler request: To fetch work.
Wed Oct 29 13:57:37 2014 | SETI@home | Reporting 1 completed tasks
Wed Oct 29 13:57:37 2014 | SETI@home | Requesting new tasks for CPU and ATI
Wed Oct 29 13:57:40 2014 | SETI@home | Scheduler request completed: got 1 new tasks
Wed Oct 29 14:02:47 2014 | SETI@home | Sending scheduler request: To fetch work.
Wed Oct 29 14:02:47 2014 | SETI@home | Reporting 1 completed tasks
Wed Oct 29 14:02:47 2014 | SETI@home | Requesting new tasks for CPU and ATI
Wed Oct 29 14:02:49 2014 | SETI@home | Scheduler request completed: got 2 new tasks
Wed Oct 29 14:21:15 2014 | SETI@home | Sending scheduler request: To fetch work.
Wed Oct 29 14:21:15 2014 | SETI@home | Requesting new tasks for CPU and ATI
Wed Oct 29 14:21:17 2014 | SETI@home | Scheduler request completed: got 1 new tasks

http://setiathome.berkeley.edu/results.php?hostid=6796479

HAL9000 wrote:

I have an old first gen Intel iMAC. I noticed it wasn't downloading and AP v7 work. I seem to recall hearing that 64-bit Intel was going to be a requirement for future releases? Looking at the list of apps I see "Mac OS/X 10.3+ 7.00" under AP v7. Is that an app for PPC and/or hardware with OS X.3?

Seems to be for PPC anyway. My G5 (PPC, running OS X 10.5) downloaded it and a task this morning and seems to have got through the first hour OK.

---

NG

HAL9000 wrote:

I have an old first gen Intel iMAC. I noticed it wasn't downloading and AP v7 work. I seem to recall hearing that 64-bit Intel was going to be a requirement for future releases? Looking at the list of apps I see "Mac OS/X 10.3+ 7.00" under AP v7. Is that an app for PPC and/or hardware with OS X.3?

Seems to be for PPC anyway. My G5 (PPC, running OS X 10.5) downloaded it and a task this morning and seems to have got through the first hour OK.

I figured it would be for that. Good to know for sure. PPC & 64-bit Intel are much large groups than 32-bit Intel in MAC land.

---

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

So I just noticed something new, at least to me.

I had just readjusted my ffa values up to higher settings to test something with another user. I had left it there as my system has around 16 GB of Ram and I wasn't worried about those AP "huggers" previously mentioned.

This is the AP unit

ap_13jn10ab_B6_P1_00107_20141101_19799.wu_1

Anyway, I got one and was watching it for over the past hour. It progressed to 33 % complete and 1.7 GB of memory. What caught my eye was the CPU utilization went all the way up to 96% I continued to watch this and soon enough, the AP crashed and restarted. It did this 2 more times before I reset the values in the FFA to lower values. I switched it to the following

-ffa_block 8192 -ffa_block_fetch 4096

Anyway, so Ram Usage is under 1 GB but CPU utilization continues to climb over 90% and when it hits some value in the upper 90% it crashes back and restarts again at around 2-3% progress.

So it's done this 5 times total now, 3 times at the higher settings and 2 times at the lower now.

Is this the same thing that Juan and Raistmer were talking about? Because I thought it was only the RAM they were talking about.

I'm going to keep letting it run and see if it ever completes.

Any ideas?

Edit..

OK, so it's the same problem that others have seen and they are working on. What I get for not paying more attention the first time around. Sorry about that folks. I know they are working on a fix for it now. Everyone have a good night


Zalster

Any ideas?

Edit..

OK, so it's the same problem that others have seen and they are working on. What I get for not paying more attention the first time around. Sorry about that folks. I know they are working on a fix for it now. Everyone have a good night

Zalster

Was that with r2721 or r2737?

---

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

Lunatic v 0.43 I haven't tried any of Raistmer's new apps yet. tomorrow maybe...it's going to be a long night..

Thats the reason why r_2737 has been released.

---

With each crime and every kindness we birth our future.

Thats the reason why r_2737 has been released.

Well, it's been made available as a public Beta test - not a full release yet.

Read the posts in the Installer v0.43 Release Notes thread about the issues involved in switching between Beta and Release applications.

Thats the reason why r_2737 has been released.

Well, it's been made available as a public Beta test - not a full release yet.

Read the posts in the Installer v0.43 Release Notes thread about the issues involved in switching between Beta and Release applications.

I noticed that of course.

---

With each crime and every kindness we birth our future.

Thats the reason why r_2737 has been released.

Well, it's been made available as a public Beta test - not a full release yet.

Read the posts in the Installer v0.43 Release Notes thread about the issues involved in switching between Beta and Release applications.

I noticed that of course.

Of course you did. Just making sure that all the other readers of this thread notice it as well.