Purely in a spirit of exploration and adventure (running v6.6.36), earlier today, I changed my web-based preferences to:

Run only the selected applications SETI@home Enhanced:      no
                                             Astropulse:    yes
                                             Astropulse v5: yes
 
If no work for selected applications is available, accept work from other applications? yes 
Use Graphics Processing Unit (GPU) if available yes 
Use Central Processing Unit (CPU) yes 

This configuration has been suggested as a way of maximising the possibility of picking up AP WU's but still getting MB WU's of no AP's are available.

Sure enough on the next Work Request the response came back:

Message from server: No work can be sent for the applications you have selected
Message from server: No work is available for Astropulse v5
Message from server: You have selected to receive work from other applications if no work is available for the applications you selected
Message from server: Sending work from other applications

and a bunch of WU's proceeded to download - but they were 6.08 CUDA WU's!

The server-end logic would seem to be:

- This Work Request is for CPU WU's; Oops, there are no AP WU's but "other applications" is set so we'll send MB [note still in CPU WU's mode]
- Ahhh... "Enhanced" is set to "no" but there is a GPU so we'll send them as CUDA's [despite the fact that the request was for CPU work].

It would appear to me that this could result in an uncontrolled growth of the CUDA cache since the CPU will keep issuing work requests for larger and larger amounts of work which are responded to with larger and larger supplies of CUDA WU's until something gets into deadline trouble and EDF mode stops further work requests.

Before I put this up on Alpha, does this ring any bells out there? Or is there something patently obvious that I have overlooked (not unusual!).

F.

---

I checked your PC -
Looks like that you run with opt apps - Cuda standard.

For me when I use an App_info.xml and dont want cuda-work
I have to remove the Cuda-parts in in App_info.

In short - you have an app_info - then the webprefs are not valid.

my 2 cents

The problem is that the host was requesting CPU work but got GPU work, which should only be sent when requested, lest the GPU queue overflows.

You're right, I do have an app_info.xml. While the absence of a work-type in the app_info will prevent that type being received, it doesn't totally over-ride the web-based preferences. For example, I have AP v5 covered in the app_info, but if I set my web-based preferences to "AP V5 = no" and "... accept work from other applications = no" then I won't get any AP WU's.

In concept, the app_info is telling Boinc what application to use to crunch each work type. If Boinc decides there is no application defined to crunch a particular work type then the server will not send it regardless of the preferences. If there is and application defined to crunch a work type, then the preferences will (should) be honoured.

F.

---

No such thing as CPU or GPU work to the Seti server. (Maybe that new BM message could use a slight syntax change?)
It is your boinc client that does the branding for CPU or GPU work. It sounds like you already had CPU work..from other project? So the Seti MB's were branded as GPU. After GPU cache is full BM would begin filling the CPU. Web preferences are only to tell BM to use CPU/GPU.

Both ques may not always be full but they shouldn't be empty either. So far 6.6.23 seems to be doing this just fine as I always get more work in one right before it runs out.

This is unless something changed...hard to keep up sometimes these days..
Hope that is of some help and someone can confirm/correct me.

---

"The most exciting phrase to hear in science, the one that heralds new discoveries, is not Eureka! (I found it!) but rather, 'hmm... that's funny...'" -- Isaac Asimov

No such thing as CPU or GPU work to the Seti server. (Maybe that new BM message could use a slight syntax change?)
It is your boinc client that does the branding for CPU or GPU work. It sounds like you already had CPU work..from other project? So the Seti MB's were branded as GPU. After GPU cache is full BM would begin filling the CPU. Web preferences are only to tell BM to use CPU/GPU.

Both ques may not always be full but they shouldn't be empty either. So far 6.6.23 seems to be doing this just fine as I always get more work in one right before it runs out.

This is unless something changed...hard to keep up sometimes these days..
Hope that is of some help and someone can confirm/correct me.

I know that the MB WU's are identical whether "branded" as 6.03 or 6.08 and that branding can be adjusted in the client to direct them to GPU or CPU. However, the intent, IMHO, is to maintain separate (virtual) queues on the host for CPU and GPU, both of which match the "extra work" specified (in my case 3 days) + the Connect Interval (0.1 days). So I believe that the server is doing the initial "branding" of MB WU's at the point of issue - if I ask for GPU work it should send 6.08's, if I ask for CPU work it should AP and/or 6.03's.

Certainly neither cache was full on my machine since I am rebuilding it after a detach / re-attach to clear the dross left by my abortive attempt to load v6.6.34. Nevertheless, I don't believe I should receive CUDA WU's in response to a work request for CPU work.

F.

---

So I believe that the server is doing the initial "branding" of MB WU's at the point of issue - if I ask for GPU work it should send 6.08's, if I ask for CPU work it should AP and/or 6.03's.

I can't see how. Multi beam is multibeam. The designation of 6.08 or 6.03 is done on the user's system.

---

Grant
Darwin NT

Then why does the user system forget what it requested and assign receive workunits to whatever? Instead of what the users system requested, be it cpu or gpu.

Quite right Kevin I have reached my 1000 per day limit according to the scheduler.
Problem is I have 8 cores 2 of which have a couple of Ap reissues which will finish in 2 hrs,the other 6 with nothing to do.
However I have 480 tasks to do on my 2 gpu's about 14 hrs work.

14/06/2009 07:38:29 SETI@home Requesting new tasks
14/06/2009 07:38:32 SETI@home Started upload of 22mr09ad.13233.6616.11.8.82_0_0
14/06/2009 07:38:35 SETI@home Finished upload of 22mr09ad.13233.6616.11.8.82_0_0
14/06/2009 07:38:35 SETI@home Scheduler request completed: got 0 new tasks
14/06/2009 07:38:35 SETI@home Message from server: (Project has no jobs available)
14/06/2009 07:39:52 SETI@home Sending scheduler request: To fetch work.
14/06/2009 07:39:52 SETI@home Reporting 1 completed tasks, requesting new tasks
14/06/2009 07:39:57 SETI@home Scheduler request completed: got 0 new tasks
14/06/2009 07:39:57 SETI@home Message from server: No work sent
14/06/2009 07:39:57 SETI@home Message from server: No work is available for SETI@home Enhanced
14/06/2009 07:39:57 SETI@home Message from server: No work is available for Astropulse v5
14/06/2009 07:39:57 SETI@home Message from server: (reached daily quota of 1000 results)
14/06/2009 07:39:57 SETI@home Message from server: (Project has no jobs available)


To keep my room warm I will attach to another project for the time being.
If everyone who has no work to do does that other projects may run dry.lol

---

So I believe that the server is doing the initial "branding" of MB WU's at the point of issue - if I ask for GPU work it should send 6.08's, if I ask for CPU work it should AP and/or 6.03's.

I can't see how. Multi beam is multibeam. The designation of 6.08 or 6.03 is done on the user's system.

There is a switch in the web-based preferences: "Use GPU if available". If the server played no part in branding the MB WU's as 603 or 608 then that switch is totally pointless.

F.

---

So I believe that the server is doing the initial "branding" of MB WU's at the point of issue - if I ask for GPU work it should send 6.08's, if I ask for CPU work it should AP and/or 6.03's.

I can't see how. Multi beam is multibeam. The designation of 6.08 or 6.03 is done on the user's system.

There is a switch in the web-based preferences: "Use GPU if available". If the server played no part in branding the MB WU's as 603 or 608 then that switch is totally pointless.

?
That switch does as it says- use GPU if available. If it's not selected & the GPU is available it won't be used. If it's selected & the GPU is available then it will be used.
If the Work Unit is allocated to the GPU, then it will get 6.08, if it's CPU it will get 6.03 (or in my case it gets 5.28)
The application that it's allocated to is what determines the application version number it receives.

---

Grant
Darwin NT

So I believe that the server is doing the initial "branding" of MB WU's at the point of issue - if I ask for GPU work it should send 6.08's, if I ask for CPU work it should AP and/or 6.03's.

I can't see how. Multi beam is multibeam. The designation of 6.08 or 6.03 is done on the user's system.

There is a switch in the web-based preferences: "Use GPU if available". If the server played no part in branding the MB WU's as 603 or 608 then that switch is totally pointless.

?
That switch does as it says- use GPU if available. If it's not selected & the GPU is available it won't be used. If it's selected & the GPU is available then it will be used.
If the Work Unit is allocated to the GPU, then it will get 6.08, if it's CPU it will get 6.03 (or in my case it gets 5.28)
The application that it's allocated to is what determines the application version number it receives.

Exactly. And that switch is at the server end (on the web-based preferences). So it is the server that is initially branding the WU as a 603 or a 608 when it issues it.

F.

---

Exactly. And that switch is at the server end (on the web-based preferences). So it is the server that is initially branding the WU as a 603 or a 608 when it issues it.

F.

As you can see in the <result> sections of sched_reply_setiathome.berkeley.edu.xml

<result>
<report_deadline>1245579404</report_deadline>
<wu_name>30mr09aa.18799.23385.16.8.193</wu_name>
<name>30mr09aa.18799.23385.16.8.193_0</name>
<file_ref>
<file_name>30mr09aa.18799.23385.16.8.193_0_0</file_name>
<open_name>result.sah</open_name>
</file_ref>
<platform>windows_intelx86</platform>
<version_num>528</version_num>
<plan_class></plan_class>
</result>

(plan_class [empty] ==> CPU)

Exactly. And that switch is at the server end (on the web-based preferences). So it is the server that is initially branding the WU as a 603 or a 608 when it issues it.

F.

As you can see in the <result> sections of sched_reply_setiathome.berkeley.edu.xml

<result>
<report_deadline>1245579404</report_deadline>
<wu_name>30mr09aa.18799.23385.16.8.193</wu_name>
<name>30mr09aa.18799.23385.16.8.193_0</name>
<file_ref>
<file_name>30mr09aa.18799.23385.16.8.193_0_0</file_name>
<open_name>result.sah</open_name>
</file_ref>
<platform>windows_intelx86</platform>
<version_num>528</version_num>
<plan_class></plan_class>
</result>

(plan_class [empty] ==> CPU)

Which brings me back to my original point:

Should the server interpret the switch "If no work for selected applications is available, accept work from other applications? yes " as "I can send GPU WU's to fulfil a CPU work request"?? The answer is obviously "No" but I would welcome independent verification of this observed behaviour before I raise it as a bug.

F.

---

Which brings me back to my original point:

Should the server interpret the switch "If no work for selected applications is available, accept work from other applications? yes " as "I can send GPU WU's to fulfil a CPU work request"?? The answer is obviously "No" but I would welcome independent verification of this observed behaviour before I raise it as a bug.

F.

It would help your report if you can catch a request/reply pair which clearly shows a CPU work request (and 0.00 seconds GPU request), but a '<plan_class>CUDA' reply.

Also, distinguish between the app_info.xml case and the stock case. My belief (unconfirmed) is that app_info trumps the 'use GPU' website switch: if you have a CUDA app listed in app_info, I believe you will get CUDA work, even if the GPU website switch is set to 'off'.

It would help your report if you can catch a request/reply pair which clearly shows a CPU work request (and 0.00 seconds GPU request), but a '<plan_class>CUDA' reply.

Also, distinguish between the app_info.xml case and the stock case. My belief (unconfirmed) is that app_info trumps the 'use GPU' website switch: if you have a CUDA app listed in app_info, I believe you will get CUDA work, even if the GPU website switch is set to 'off'.

Thanks, Richard. I will go into debug mode and see what I can capture. If your second sentence is correct, then I would see that as another bug, but whatever in that case, CUDA work should not be supplied in response to a CPU work request so I will focus on trying to demo that for the moment.

F.

---

My S@H preferences are all set to yes means I will accept any work.
However I have more than enough 6.08 Cuda, 960 tasks to be exact.
I am still receiving 6.08 tasks periodically.
Although my i7's 8 cores are not being used I did not receive any 6.03 tasks.
Seems odd.
I have opted to crunch on another project to use the cpu until the issue of cpu tasks is resolved.
Dave

---

Thanks, Richard. I will go into debug mode and see what I can capture. If your second sentence is correct, then I would see that as another bug, but whatever in that case, CUDA work should not be supplied in response to a CPU work request so I will focus on trying to demo that for the moment.

I've not got a nvidia, but wouldn't scheduler_request_*.xml include <cuda_req_...> or <gpu_req_...> or something if you're asking for cuda-work, and only <cpu_req_secs> if you're asking for cpu-work?

If so, you should include a scheduler_request_* asking only for CPU and scheduler_reply_* with CUDA-work assigned in your bug-report.

You should remove the Authenticator in the bug-report...

---

"I make so many mistakes. But then just think of all the mistakes I don't make, although I might."

I've not got a nvidia, but wouldn't scheduler_request_*.xml include <cuda_req_...> or <gpu_req_...> or something if you're asking for cuda-work, and only <cpu_req_secs> if you're asking for cpu-work?

If so, you should include a scheduler_request_* asking only for CPU and scheduler_reply_* with CUDA-work assigned in your bug-report.

You should remove the Authenticator in the bug-report...

Thanks for that steer. That will make it much easier to explain what is happening once I manage to snag another occurrence. FYI, the request includes a <plan_class>CUDA</plan_class> for GPU and <plan_class></plan_class> for CPU (don't really understand why this is not just <plan_class/>).

F.

---

My experience with BOINC 6.6.36 is similar to yours.

This morning I had 108 CUDA wu's in Tasks and 0 CPU wu's. Apparently, both cpu cores of my E8400 had been sitting idle since sometime late last night.

This situation makes absolutely no sense to me. Why wouldn't the project want all available resources to be in use? WU predisposition is a BIG mistake, IMNSHO. What would happen on your machine if you suddenly lost CUDA capability due to a card failure, or whatever? 960 "CUDA" wu's are stranded? Absurd.

So, I aborted 107 "CUDA" wu's and let the last one complete, and then uninstalled the "recommended version" of BOINC and reinstalled 6.4.7.

Martin