Don't think that follows from the above. Original issue was that after running 0.43b, I had to manually edit the .cl file to change the bool statement. That's not related to the fact that the APs had previously run and failed, logging a 2721 attempt each pass. Separate issue, imho.

Did you actually see tasks restarting, failing, backing off, trying again... after you'd run the v0.43b installer and allowed BOINC to restart? I'd have expected them to start running cleanly straight away with no further ado, though of course there would have been other tasks still 'waiting to run' from the failed rev 2721 attempts.

As I mentioned in my first answer, there are still bool2 references in the rev 2887 .cl file, but they are in the inactive legacy path. So your search/replace would have found things to change, but I honestly don't think you 'had' to go through that additional step - we've had something over 3,000 downloads of v0.43b since release, and nobody else has reported having to edit the current .cl file.

I did not see any stops and restarts after running 0.43b. Issue only came up when I looked at the completed workunit I referred to (and others) and saw all the abnormal error messages at the top. I can say that it appeared to me as though APs I was first touching after running the installer had the issue. I just went and looked at the working directory, and the 2721 executable does not exist, so clearly all this nonsense must have somehow been related to the process I followed doing the upgrades.

Again, sorry for the false alarm, but not sorry for the learning experience:)

---

Again, sorry for the false alarm, but not sorry for the learning experience:)

Exactly. Always happy to check out a report (I do the same thing with possible virus alerts), and even happier to learn from a false alarm that I don't have any extra work to do!

Again, sorry for the false alarm, but not sorry for the learning experience:)

Exactly. Always happy to check out a report (I do the same thing with possible virus alerts), and even happier to learn from a false alarm that I don't have any extra work to do!

Well, I should have made a backup of the cl file before doing the edit, so I could fall back. But I'm sure any future installer will deal with that if needed. Ever get sick of learning the same lessons over and over again? I know I do!
Anyway, much appreciated and always hoping I can find a way to give back to you guys for the work you do!

---

'Twas a nice AP run indeed.
I think the kitties managed to snatch up 6-700 of the tasty little morsels.
Which they then turned over to the crunchers.

Did not really expect Matt's AP sorting to be done so soon.
Nice work, Matt!

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

AP splitting should begin soon because I just loaded up with MBs ... As Murphy says ....

---

Is this the day it will happen? Multiple channels of AP's being split/splat/splut? AP channels being added one after the other for a week or a year? :-)

Or is this just another day of boring, low credit/hour MB's?

I think I know the answer already :-(

Well....the kitties managed to scratch up about 65 APs during the little run last night.
Hoping for more to come.
Maybe Matt will get that new shipment from Arecibo soon.............

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

Ooooo..Whoopee! I finally snagged one............one.

[edit] I'm up to a whopping 3 now!

---

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

Well, my 10-day cache got re-filled. I was down to about 4 days remaining, and the WUs began pouring in. I ended up getting 38 before BOINC stopped asking for more work.

---

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

This is related to AstroPulse, but I think problem is in BOINC.

What I have observed my host and noticed that it doesn't obey FIFO order.

Example:

It got two AP units, 9 Sep 2015, 14:01:39 UTC and 9 Sep 2015, 14:06:48 UTC (currently on this tasks page, but drops all time to older pages).

In FIFO order those two AP's should been crunched already, but they are not. Even CPU MB units from that time has been processed.

What I think is that problem is that my GPU configured to run two MB task at time and one AP task at time. So when one MB task is done, BOINC starts new MB tasks, so it's never "free" to run one AP task alone.

I keep continue to observe that host does this keep going on.

This is related to AstroPulse, but I think problem is in BOINC.

What I have observed my host and noticed that it doesn't obey FIFO order.

Example:

It got two AP units, 9 Sep 2015, 14:01:39 UTC and 9 Sep 2015, 14:06:48 UTC (currently on this tasks page, but drops all time to older pages).

In FIFO order those two AP's should been crunched already, but they are not. Even CPU MB units from that time has been processed.

What I think is that problem is that my GPU configured to run two MB task at time and one AP task at time. So when one MB task is done, BOINC starts new MB tasks, so it's never "free" to run one AP task alone.

I keep continue to observe that host does this keep going on.

I can address part of your question: BOINC has no problem putting a single MB task in WAIT mode and starting an AP. I see it all the time happening on my computer with a similar set up for running MB and APs.

---

SETI@home classic workunits 4,019
SETI@home classic CPU time 34,348 hours

I can address part of your question: BOINC has no problem putting a single MB task in WAIT mode and starting an AP. I see it all the time happening on my computer with a similar set up for running MB and APs.

Yes, that's true, but it doesn't do that in FIFO -order.

9/12/2015 9:31:15 AM | SETI@home | No tasks sent
9/12/2015 9:31:15 AM | SETI@home | No tasks are available for AstroPulse v7
9/12/2015 9:31:15 AM | SETI@home | Tasks for AMD/ATI GPU are available, but your preferences are set to not accept them
9/12/2015 9:36:20 AM | SETI@home | Sending scheduler request: To fetch work.
9/12/2015 9:36:20 AM | SETI@home | Requesting new tasks for NVIDIA GPU
9/12/2015 9:36:22 AM | SETI@home | Scheduler request completed: got 0 new tasks

I'm getting real tired of this message. Discrimination at work or just not very many AMD/ATI GPUs out there to process? Or are nvidia GPUs more efficient and faster so always creating a dearth of APs?

Regardless, I am going dark until there is sufficient work to keep the navy crunching.

---

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

AP tasks will always be in short supply compared to MB tasks. Nvidia are very good at crunching APs, "standard" and "shorty" MBs, but the lesser Nvidia cards fall flat on their face when it comes to VLARs. Roll on the day when the OpneCL MB application is released - I guess there is still a shortage of MAC(?) testers to get to release state....

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Roll on the day when the OpneCL MB application is released

Should I read from this that MB OpenCL will enable VLAR on NVidia?

---

I think it has more to do with Eric's #1 Machine scoring inconclusive on just about Every SETI@home v7 v7.08 (opencl_nvidia_sah) task, http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=75197&offset=40. Most of them eventually validate, but a good number end as invalid. Until you see that machine working better, I doubt you will see opencl_nvidia_sah released anytime soon. The ATI version seems to be working fine and hopefully the Linux ATI version will be on Main soon as the current version is rather old.

I think it has more to do with Eric's #1 Machine scoring inconclusive on just about Every SETI@home v7 v7.08 (opencl_nvidia_sah) task, http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=75197&offset=40. Most of them eventually validate, but a good number end as invalid. Until you see that machine working better, I doubt you will see opencl_nvidia_sah released anytime soon. The ATI version seems to be working fine and hopefully the Linux ATI version will be on Main soon as the current version is rather old.

Which is too bad, I've got almost a thousand valid on my machine.

SETI@home v7 7.08 windows_intelx86 (opencl_nvidia_sah)
Number of tasks completed 915
Max tasks per day 974
Number of tasks today 50
Consecutive valid tasks 941
Average processing rate 293.23 GFLOPS
Average turnaround time 0.06 days


Could it be the card? Just random thought

---

I think it has more to do with Eric's #1 Machine scoring inconclusive on just about Every SETI@home v7 v7.08 (opencl_nvidia_sah) task, http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=75197&offset=40. Most of them eventually validate, but a good number end as invalid. Until you see that machine working better, I doubt you will see opencl_nvidia_sah released anytime soon. The ATI version seems to be working fine and hopefully the Linux ATI version will be on Main soon as the current version is rather old.

Which is too bad, I've got almost a thousand valid on my machine.

SETI@home v7 7.08 windows_intelx86 (opencl_nvidia_sah)
Number of tasks completed 915
Max tasks per day 974
Number of tasks today 50
Consecutive valid tasks 941
Average processing rate 293.23 GFLOPS
Average turnaround time 0.06 days


Could it be the card? Just random thought

The last I'd heard it had been isolated to the Driver. Something about having to use a 35x.xxx driver or you get what Eric gets? I've been busy with other things, is it Still the same? What happens if you use the same driver as Eric's machine? I don't think forcing people to use the latest driver is going to work very well, if that's the problem.

unfortunately I'm not at my machines. Can't test that theory until at least Monday of next week.

I've got a new machine I can task to run for a few hours. I'll put the newest driver on it and we will see if they invalidate or not. But again, not till Monday

edit...

Checking the valids I have already. Last Driver was 353.30

---

unfortunately I'm not at my machines. Can't test that theory until at least Monday of next week.

I've got a new machine I can task to run for a few hours. I'll put the newest driver on it and we will see if they invalidate or not. But again, not till Monday

edit...

Checking the valids I have already. Last Driver was 353.30

FWIW, I'm having good luck on both machine running 355.82 with my 750TIs. One x32, one x64 ...

---

FWIW, I'm having good luck on both machine running 355.82 with my 750TIs. One x32, one x64 ...

I am having good results with this, 355.82, version as well on my 750TIs.

---

SETI@home classic workunits 4,019
SETI@home classic CPU time 34,348 hours