Scenario one Running 3 MB:
0.33 + 0.33 + 0-33 = 0-99. Now one MB quits -> only 0.33 + 0.33 = 0.66 running -> can start new AP. Now running 0.33+0.33+0.34=1.00 .

Scenario two Running one AP and two MB:
0.34 + 0.33 + 0.33 = 1.00- Now one MB finishes. Runnung 0.34 + 0.33 = 0.67. Can start a new MB or if an AP is scheduled to run next must wait for more free GPU.

Three: running 2 AP = 0.68. Must wait. After the other AP finishes can start AP or MB.

Scenarios one and three behave as expected. It's the "Scenario two" where BOINC is inconsistent. Most of the time, it will start a new MB whether or not an AP is the next task at the top of the queue (which is what I assume you mean by "scheduled"). That AP (and sometimes several APs) will remain in a "Ready to start" status until another AP finishes and frees up that .34 GPU. MBs that are lower in the queue will be started ahead of the APs if only .33 is available. Normally, the only time 2 APs run on a single GPU is when the 2 MBs running with the first AP happen to finish simultaneously (or nearly so).

But every once in awhile, BOINC lets an MB finish without starting another task of any kind. On rare occasions, it will actually do that on two different GPUs. Then, when the final MB finishes on one of the GPUs, it will go ahead and start a second AP on that GPU while simultaneously starting the next available MB on the second GPU. I've never been able to identify a pattern in any of this. :^)

Yes, I have seen that same and it does seem inconsistent to me too, but I guess that the 'next' in queue is not defined by deadline alone and may be not first in first out order either.

The average wait time for tasks is minimized if short tasks are processed first even though the throughput remains the same.

---

To overcome Heisenbergs:
"You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones

Computing times for AP7 seem to differ a lot more then those for V6. I get everything from ~3000 secs to ~7000 secs. Here's an example for one of the tasks that take longer: http://setiathome.berkeley.edu/result.php?resultid=3793228139

On V6 allmost all tasks were ~5000 secs for me, except the heavily blanked ones of course.

Any explanation for that?

---

Computing times for AP7 seem to differ a lot more then those for V6. I get everything from ~3000 secs to ~7000 secs. Here's an example for one of the tasks that take longer: http://setiathome.berkeley.edu/result.php?resultid=3793228139

On V6 allmost all tasks were ~5000 secs for me, except the heavily blanked ones of course.

Any explanation for that?

How many tasks are you running at the same time ? I am also using a GTX-750 (2 tasks at the same time) and the times for the tasks seems to depend on what else is running on the GPU at the same time. If two Astropulse tasks are running I see times with an average of a little less than 5000 seconds per taks. But if something else is running at the same time (e.g. Multibeam or Einstein) the Astropulse task seems to take more than its fair share of resources and it finishes a little faster (usually less than 4000 seconds).

Tom

---

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?

---

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.

---

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?

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.

---

With each crime and every kindness we birth our future.

I see that there is a 32-bit SSE3 version of the AP7 app for Windows (AP7 32-bit SSE3 CPU r2691), but there is none for Linux. Is that because there is no real advantage to using SSE3 instructions with Linux or is it just not posted yet?

Not posted. The other versions should come up one after the other over the next two weeks.

Thank you and a tip of the hat to the authors as well. It is installed and seems to be chugging along nicely.

Anyone worked out explaining the credits yet?
I thought it was percentage blanked that has to do with it, but seeing how if you're a credit runner you want to run only AP7s with ~2.41 percent blanked to get the 'mother load', I doubt that that's it.

My present run:
percent blanked: 0.00 -- 465.21
percent blanked: 13.25 -- 488.16
percent blanked: 2.41 -- 534.16
percent blanked: 2.41 -- 521.47
percent blanked: 0.00 -- 455.75
percent blanked: 0.00 -- 491.06

Now had 5 of those 13.25% blanked so still got a couple to go before the server allows my cache to be more than just one AP and the rest air on a work request. ;-)

---

Anyone worked out explaining the credits yet?
I thought it was percentage blanked that has to do with it, but seeing how if you're a credit runner you want to run only AP7s with ~2.41 percent blanked to get the 'mother load', I doubt that that's it.

My present run:
percent blanked: 0.00 -- 465.21
percent blanked: 13.25 -- 488.16
percent blanked: 2.41 -- 534.16
percent blanked: 2.41 -- 521.47
percent blanked: 0.00 -- 455.75
percent blanked: 0.00 -- 491.06

Now had 5 of those 13.25% blanked so still got a couple to go before the server allows my cache to be more than just one AP and the rest air on a work request. ;-)

I think the number & type of pulses are a factor as well. Not just blanking.

---

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

One of my computers (ID: 3324167) runs:
Microsoft Windows Vista
Ultimate x64 Edition, Service Pack 2, (06.00.6002.00)

with the following CPU:
GenuineIntel
Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz [Family 6 Model 15 Stepping 6]
(2 processors)

and the following GPU:
NVIDIA GeForce 8800 GTS (613MB) driver: 280.26 OpenCL: 1.0

Under 0.41 it has successfully run both SETI Multibeam v7 and AP v6 on both the CPU and GPU. I upgraded from Lunatics 0.41 to 0.43 two days ago. I am currently trying to run just APs on it. My preferences are set to run both NVIDIA GPU and AP v7. SETI is requesting both GPU and CPU units, but I am only getting CPU AP v7 units.

There are no AP v6 units left on my machine, and I am set to the maximum work buffers. I have checked the documentation with 0.43, and I believe I am reading that my GPU should be able to process AP v7 units.

Can anyone see what might be preventing me from getting the GPU units? I would certainly appreciate any insight you can give me.

Thanks!

Anyone worked out explaining the credits yet?
I thought it was percentage blanked that has to do with it, but seeing how if you're a credit runner you want to run only AP7s with ~2.41 percent blanked to get the 'mother load', I doubt that that's it.

My present run:
percent blanked: 0.00 -- 465.21
percent blanked: 13.25 -- 488.16
percent blanked: 2.41 -- 534.16
percent blanked: 2.41 -- 521.47
percent blanked: 0.00 -- 455.75
percent blanked: 0.00 -- 491.06

Now had 5 of those 13.25% blanked so still got a couple to go before the server allows my cache to be more than just one AP and the rest air on a work request. ;-)

My highest credit grant so far was 531.87 on WU 1620264972, with over 60% blanking.

The reference for credit scaling is an average, for this project (and probably all others using CreditNew) it is based on the stock CPU app versions compared to the host CPU Whetstone benchmarks. That average will eventually approach an asymptote, but not until most hosts running stock CPU have enough tasks averaged to get the best version for their platform on most work requests.

Of course I put <flops> in app_info.xml as soon as I converted to anonymous platform so the run time estimates were close from the beginning and work fetch sensible. That has nothing to do with credits, and having done many AP v7 tasks at SETI Beta the needed values were easy to choose.

                                                                  Joe

...Can anyone see what might be preventing me from getting the GPU units? I would certainly appreciate any insight you can give me.

Thanks!

It should be receiving work. Try posting the first part of your startup log including the following;

10/25/2014 10:54:39 |  | Starting BOINC client version 7.2.33 for windows_intelx86
10/25/2014 10:54:39 |  | CUDA: NVIDIA GPU 0: GeForce 8800 GT (driver version 266.58, CUDA version 3.2, compute capability 1.1, 512MB, 466MB available, 544 GFLOPS peak)
10/25/2014 10:54:39 |  | OpenCL: NVIDIA GPU 0: GeForce 8800 GT (driver version 266.58, device version OpenCL 1.0 CUDA, 512MB, 466MB available, 544 GFLOPS peak)
10/25/2014 10:54:39 | SETI@home | Found app_info.xml; using anonymous platform
10/25/2014 10:54:39 |  | Processor: 2 GenuineIntel Intel(R) Xeon(R) CPU            3060  @ 2.40GHz [Family 6 Model 15 Stepping 6]
10/25/2014 10:54:39 |  | OS: Microsoft Windows XP: Professional x86 Edition, Service Pack 3, (05.01.2600.00)
10/25/2014 10:54:40 | SETI@home | Sending scheduler request: To fetch work.
10/25/2014 10:54:40 | SETI@home | Requesting new tasks for CPU
10/25/2014 10:54:41 | SETI@home | Scheduler request completed: got 1 new tasks
10/25/2014 14:43:48 | SETI@home | Sending scheduler request: To fetch work.
10/25/2014 14:43:48 | SETI@home | Requesting new tasks for NVIDIA
10/25/2014 14:43:49 | SETI@home | Scheduler request completed: got 1 new tasks...

Here it is:

10/25/2014 9:48:06 PM | | Starting BOINC client version 7.2.42 for windows_x86_64
10/25/2014 9:48:06 PM | | log flags: file_xfer, sched_ops, task
10/25/2014 9:48:06 PM | | Libraries: libcurl/7.25.0 OpenSSL/1.0.1 zlib/1.2.6
10/25/2014 9:48:06 PM | | Data directory: D:\Boinc\Data
10/25/2014 9:48:06 PM | | Running under account David
10/25/2014 9:48:06 PM | | CUDA: NVIDIA GPU 0: GeForce 8800 GTS (driver version 280.26, CUDA version 4.0, compute capability 1.0, 613MB, 533MB available, 408 GFLOPS peak)
10/25/2014 9:48:06 PM | | OpenCL: NVIDIA GPU 0: GeForce 8800 GTS (driver version 280.26, device version OpenCL 1.0 CUDA, 613MB, 533MB available, 408 GFLOPS peak)
10/25/2014 9:48:06 PM | SETI@home | Found app_info.xml; using anonymous platform
10/25/2014 9:48:06 PM | | Host name: Core2Duo
10/25/2014 9:48:06 PM | | Processor: 2 GenuineIntel Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz [Family 6 Model 15 Stepping 6]
10/25/2014 9:48:06 PM | | Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss htt tm pni ssse3 cx16 syscall nx lm vmx tm2 pbe
10/25/2014 9:48:06 PM | | OS: Microsoft Windows Vista: Ultimate x64 Edition, Service Pack 2, (06.00.6002.00)
10/25/2014 9:48:06 PM | | Memory: 4.00 GB physical, 8.20 GB virtual
10/25/2014 9:48:06 PM | | Disk: 93.14 GB total, 19.69 GB free
10/25/2014 9:48:06 PM | | Local time is UTC -5 hours
10/25/2014 9:48:06 PM | | Config: don't compute while hugin.exe is running
10/25/2014 9:48:06 PM | | Config: don't compute while PowerDVD.exe is running
10/25/2014 9:48:06 PM | | Config: don't compute while Xenus.exe is running
10/25/2014 9:48:06 PM | | Config: don't use GPUs while hugin.exe is running
10/25/2014 9:48:06 PM | climateprediction.net | URL http://climateprediction.net/; Computer ID 647489; resource share 100
10/25/2014 9:48:06 PM | Einstein@Home | URL http://einstein.phys.uwm.edu/; Computer ID 4125225; resource share 0
10/25/2014 9:48:06 PM | SETI@home | URL http://setiathome.berkeley.edu/; Computer ID 3324167; resource share 100
10/25/2014 9:48:06 PM | SETI@home | General prefs: from SETI@home (last modified 08-Sep-2011 01:07:05)
10/25/2014 9:48:06 PM | SETI@home | Computer location: home
10/25/2014 9:48:06 PM | | General prefs: using separate prefs for home
10/25/2014 9:48:06 PM | | Reading preferences override file
10/25/2014 9:48:06 PM | | Preferences:
10/25/2014 9:48:06 PM | | max memory usage when active: 2046.82MB
10/25/2014 9:48:06 PM | | max memory usage when idle: 3684.27MB
10/25/2014 9:48:06 PM | | max disk usage: 14.00GB
10/25/2014 9:48:06 PM | | (to change preferences, visit a project web site or select Preferences in the Manager)
10/25/2014 9:48:06 PM | | Not using a proxy
10/25/2014 9:48:08 PM | SETI@home | Sending scheduler request: To fetch work.
10/25/2014 9:48:08 PM | SETI@home | Requesting new tasks for NVIDIA
10/25/2014 9:48:09 PM | SETI@home | Scheduler request completed: got 0 new tasks
10/25/2014 9:48:09 PM | SETI@home | No tasks sent
10/25/2014 9:48:09 PM | SETI@home | No tasks are available for AstroPulse v6
10/25/2014 9:48:09 PM | SETI@home | No tasks are available for AstroPulse v7

BOINC client version 7.2.42

Hmmm. I've had 7.2.42 tell me it was stopping computing because my computer was busy. But the computer wasn't busy, and I didn't even have other projects that might possibly convince BOINC the computer was busy. I've replaced 7.2.42 with 7.2.33 on just about every host I use much.

If you have any work from other projects you might try suspending it and see if that makes a difference. You could try setting the SETI preferences to GPU only, but, I would try a different version of BOINC if it were me.

Okay, I'll give that a try. Thanks!

BOINC client version 7.2.42

Hmmm. I've had 7.2.42 tell me it was stopping computing because my computer was busy. But the computer wasn't busy, and I didn't even have other projects that might possibly convince BOINC the computer was busy. I've replaced 7.2.42 with 7.2.33 on just about every host I use much.

If you have any work from other projects you might try suspending it and see if that makes a difference. You could try setting the SETI preferences to GPU only, but, I would try a different version of BOINC if it were me.

But whether or not to crunch work already downloaded (which can be controlled by preferences) is a completely different question from whether or not the project has tasks available for download at the moment he requests them.

The Startup looks fine, but it's been days. Look at the results, days of receiving CPU work but no GPU work; http://setiathome.berkeley.edu/results.php?hostid=3324167
The only conclusion is something has convinced BOINC his card doesn't need work. He still hasn't reached 11 completed AP7 CPU tasks, so, it's possible BOINC is still trying to fill his CPU cache with 180 hour tasks and hasn't gotten around to downloading GPU tasks. But it's asking for GPU tasks...so...who knows. Tell it to stop trying to fill the CPU cache and see what happens, http://setiathome.berkeley.edu/prefs.php?subset=project

I'll elaborate on what happened over here,

There is a problem trying to convince BOINC that it really should download enough tasks on the Vista host to use all 3 cards. I've noticed that before when using a host that hasn't been used in a while. It's like pulling teeth to get BOINC to download any work. In this case APv7 hasn't been used, so, the time estimates are really long adding to the problem. Even with a 10 day cache BOINC wouldn't download enough work to keep all 3 cards working. I had to enter a FLOPS setting to get BOINC to download enough work to keep all the cards working...

In the above case BOINC Refused to send more than Two GPU tasks even though the cache was set to Ten Days and a GPU was sitting Idle. BOINC kept saying No Work Was Needed, with an Idle GPU. Two GPU tasks for 3 GPUs...10 day cache. I had to enter a FLOPS setting to get anymore GPU tasks. If it would have been just One GPU would BOINC of sent Any Tasks?

Others have Complained about only receiving CPU work until 100 tasks have been received. I've said it before, It didn't use to be that way. BOINC use to Fill the GPU cache First, then start on the CPU downloads. Would someone Please change it back to the way it was?

I'll elaborate on what happened over here,

There is a problem trying to convince BOINC that it really should download enough tasks on the Vista host to use all 3 cards. I've noticed that before when using a host that hasn't been used in a while. It's like pulling teeth to get BOINC to download any work. In this case APv7 hasn't been used, so, the time estimates are really long adding to the problem. Even with a 10 day cache BOINC wouldn't download enough work to keep all 3 cards working. I had to enter a FLOPS setting to get BOINC to download enough work to keep all the cards working...

In the above case BOINC Refused to send more than Two GPU tasks even though the cache was set to Ten Days and a GPU was sitting Idle. BOINC kept saying No Work Was Needed, with an Idle GPU. Two GPU tasks for 3 GPUs...10 day cache. I had to enter a FLOPS setting to get anymore GPU tasks. If it would have been just One GPU would BOINC of sent Any Tasks?

Others have Complained about only receiving CPU work until 100 tasks have been received. I've said it before, It didn't use to be that way. BOINC use to Fill the GPU cache First, then start on the CPU downloads. Would someone Please change it back to the way it was?

You're confusing your readers by muddling up two different things in the same post.

'No Work Was Needed' is a statement by your local BOINC client that it thinks the relevant bit of your cache is full. That sounds odd if you have an idle resource, but the way to diagnose it is to set '<work_fetch_debug>' locally and examine the figures. Better yet, install the release candidate BOINC v7.4.22, which gives a better narrative description as well as the figures. If the BOINC client fails to request work where the figures clearly indicate that it is needed, we can work together to report that as a bug.

'only receiving CPU work' (assuming you are requesting both CPU and GPU work) is a server decision. Harder to fully diagnose with facts and figures, unless you use Albert@Home which has current server code and gives you access to the servers logs as well, but you need to attempt an analysis if you want to persuade David to change something.

Right Richard. Go back and have more Coffee. There is definitely a problem with BOINC work fetch on new host/app versions. Just keep pretending there isn't. I had a similar problem over at Beta with, I believe, the same Host. I think over there it was caused by the CPUs being in Panic mode because of the long Time Estimates, and not allowing the GPUs to even run. There was another similar case here. It could be the problem in this case as well. With all those 180 hour CPU tasks I'll bet it's in Panic Mode...