Possibly preferences being ignored?

Message boards : Number crunching : Possibly preferences being ignored?
Message board moderation

To post messages, you must log in.

1 · 2 · Next

AuthorMessage
Speedy
Volunteer tester
Avatar

Send message
Joined: 26 Jun 04
Posts: 1643
Credit: 12,921,799
RAC: 89
New Zealand
Message 1760116 - Posted: 28 Jan 2016, 22:59:26 UTC

Has anyone experienced the following issue?

I have my home preferences set to only receive AP work for my CPU this works as good as gold. I have my default preferences (in the drop-down menu listed as ––) set to receive all types of work but only for Nvidia GPU. It appears when I switch my preferences from home to default using the drop-down menu under computer details I will receive a cache of MB 8 work for CPU. I believe this should not be happening since I do not have the boxes ticked to receive work from another application. The only CPU application I have selected to receive work from is the AP application.

Apart from selecting no new work under projects in Boinc Manager is there another way to do this?

I'm using windows 10 Professional 64 bit Boinc Manager 7.6.22

Unfortunately I do not have a log showing work fetch pattern
ID: 1760116 · Report as offensive
JLDun
Volunteer tester
Avatar

Send message
Joined: 21 Apr 06
Posts: 573
Credit: 196,101
RAC: 0
United States
Message 1760126 - Posted: 29 Jan 2016, 0:09:37 UTC - in response to Message 1760116.  
Last modified: 29 Jan 2016, 0:12:29 UTC

Just to double check: you are picking "HOME" before this happens, and it is set to "AP" only, "Other Work" unchecked?

EDIT: Or are you switching to default, which looks like you have it stated/set to do Any Work (all boxes checked).
ID: 1760126 · Report as offensive
Speedy
Volunteer tester
Avatar

Send message
Joined: 26 Jun 04
Posts: 1643
Credit: 12,921,799
RAC: 89
New Zealand
Message 1760140 - Posted: 29 Jan 2016, 0:35:28 UTC - in response to Message 1760126.  

Just to double check: you are picking "HOME" before this happens, and it is set to "AP" only, "Other Work" unchecked?

EDIT: Or are you switching to default, which looks like you have it stated/set to do Any Work (all boxes checked).

Yes this happens after a switch to default from home with allow work in Boinc manager selected.

Yes you are correct I have all the projects selected but I do not have the CPU option ticked on the my default profile.I only have use CPU ticked on my home profile and I only have AP work selected.

On both the default profile and home profile I have the following: If no work for selected applications is available, accept work from other applications? set to no
ID: 1760140 · Report as offensive
Rasputin42
Volunteer tester

Send message
Joined: 25 Jul 08
Posts: 412
Credit: 5,834,661
RAC: 0
United States
Message 1760153 - Posted: 29 Jan 2016, 1:22:42 UTC

I have noticed, that when i changed the preferences, the very first "project update" requested manually still uses the old settings. Only updates after that use the new settings.
Has anyone seen that behavior?
ID: 1760153 · Report as offensive
Profile HAL9000
Volunteer tester
Avatar

Send message
Joined: 11 Sep 99
Posts: 6534
Credit: 196,805,888
RAC: 57
United States
Message 1760166 - Posted: 29 Jan 2016, 2:04:43 UTC - in response to Message 1760140.  

Just to double check: you are picking "HOME" before this happens, and it is set to "AP" only, "Other Work" unchecked?

EDIT: Or are you switching to default, which looks like you have it stated/set to do Any Work (all boxes checked).

Yes this happens after a switch to default from home with allow work in Boinc manager selected.

Yes you are correct I have all the projects selected but I do not have the CPU option ticked on the my default profile.I only have use CPU ticked on my home profile and I only have AP work selected.

On both the default profile and home profile I have the following: If no work for selected applications is available, accept work from other applications? set to no

I'm pretty sure what you are seeing is the same reason I get: SETI@home Message from server: Your app_info.xml file doesn't have a usable version of SETI@home v8.
On my hosts that have their venue settings configured as:


Which for me is nothing new. I've been seeing this behavior for years.
Which is why I don't truest the venue settings 100% and modify my app_info.xml to make sure I'm only running the apps I want.
SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[
ID: 1760166 · Report as offensive
Speedy
Volunteer tester
Avatar

Send message
Joined: 26 Jun 04
Posts: 1643
Credit: 12,921,799
RAC: 89
New Zealand
Message 1760201 - Posted: 29 Jan 2016, 3:35:54 UTC

HAL, I partly hear what you are saying. One thing I can't understand is why do I receive CPU work for MB work units when I don't have any CPU option selected for that particular profile. If you remove part of your app_info file that would mean that you couldn't use that particular application at all wouldn't it? I certainly don't want to do that
ID: 1760201 · Report as offensive
Profile HAL9000
Volunteer tester
Avatar

Send message
Joined: 11 Sep 99
Posts: 6534
Credit: 196,805,888
RAC: 57
United States
Message 1760225 - Posted: 29 Jan 2016, 4:25:20 UTC - in response to Message 1760201.  
Last modified: 29 Jan 2016, 4:25:37 UTC

HAL, I partly hear what you are saying. One thing I can't understand is why do I receive CPU work for MB work units when I don't have any CPU option selected for that particular profile. If you remove part of your app_info file that would mean that you couldn't use that particular application at all wouldn't it? I certainly don't want to do that

One guess I have is that somewhere in the work fetch process the server gets confused and just sends whatever it can to fulfill a request for work. Maybe it is an issue reading the users preferences from the db during the work fetch request? I haven't seen this behavior with other projects, but not many of them get their servers beaten as hard as SETI@home.

From your first post it seems like you want to run:
AP: GPU & CPU
MB: GPU
If that is correct I would only need to have those 3 apps installed.

If you like to switch CPU MB off & on then it makes sense to leave the MB CPU installed. However sometimes the server will sneak you work for other apps despite your venue settings.
SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[
ID: 1760225 · Report as offensive
Speedy
Volunteer tester
Avatar

Send message
Joined: 26 Jun 04
Posts: 1643
Credit: 12,921,799
RAC: 89
New Zealand
Message 1760257 - Posted: 29 Jan 2016, 5:53:46 UTC - in response to Message 1760225.  

HAL, I partly hear what you are saying. One thing I can't understand is why do I receive CPU work for MB work units when I don't have any CPU option selected for that particular profile. If you remove part of your app_info file that would mean that you couldn't use that particular application at all wouldn't it? I certainly don't want to do that

One guess I have is that somewhere in the work fetch process the server gets confused and just sends whatever it can to fulfill a request for work. Maybe it is an issue reading the users preferences from the db during the work fetch request? I haven't seen this behavior with other projects, but not many of them get their servers beaten as hard as SETI@home.

From your first post it seems like you want to run:
AP: GPU & CPU
MB: GPU
If that is correct I would only need to have those 3 apps installed.

If you like to switch CPU MB off & on then it makes sense to leave the MB CPU installed. However sometimes the server will sneak you work for other apps despite your venue settings.

Thank you I was unaware that sometimes they get ignored. Hopefully one day there will be a fix
ID: 1760257 · Report as offensive
Profile Jord
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 15184
Credit: 4,362,181
RAC: 3
Netherlands
Message 1760284 - Posted: 29 Jan 2016, 8:17:07 UTC - in response to Message 1760201.  

One thing I can't understand is why do I receive CPU work for MB work units when I don't have any CPU option selected for that particular profile.

But why do you have set to run a CPU app on that profile then if you do not want to receive CPU work? If you do not want to run CPU work on that host in the first place, I'd start by setting that in the app_info.xml file.

Mostly because by using the app_info.xml file, you are telling BOINC which apps it should run with.

But, just so I can check some things and if need be send it on to the BOINC developers, can you please send me the contents of your sched_reply_setiathome.berkeley.edu.xml file's contents in a private message? You can find this file in the data directory.

I am the main moderator at the BOINC Dev forums, the BOINC developers can vouch for me, I am in direct contact with them.
ID: 1760284 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14650
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1760307 - Posted: 29 Jan 2016, 10:35:58 UTC - in response to Message 1760153.  
Last modified: 29 Jan 2016, 10:37:45 UTC

As I understand the opening post, Speedy wishes to switch between two groups of settings.

1) AP only on CPU only
2) AP and MB on NVidia only

Under anonymous platform, that can be enforced by only installing the selected apps (in particular, not installing a CPU MB application). But for stock apps it can only be done through preferences, and raises an interesting point.

I have noticed, that when i changed the preferences, the very first "project update" requested manually still uses the old settings. Only updates after that use the new settings.
Has anyone seen that behavior?

Yes, I have seen it, and that's what makes it interesting.

There are lots of preferences available in the venue settings, but let's just talk about two groups.

Hardware: CPU / ATI / NVidia / intel
Software: SaH_v7 / AP / SaH_v8 / other apps

I think they work in different ways.

The 'software' group seem to work directly on the server - they take effect immediately after you update the website.

The 'hardware' group work by sending a message back to your computer, which only takes effect for the next work request. That's because requesting work, and sending messages about preferences, use the same 'update' mechanism. The 'click update' suggested on the website for activating new preferences:

Your preferences have been updated, and will take effect when your computer communicates with SETI@home or you issue the Update command from the BOINC Manager.

can also be a work request, and will use the old hardware preferences (because the message about the change hasn't been received yet).

The strange thing (and this is perhaps one for Jord to look into) is that I seem to remember that when this mechanism was introduced, it was stated that the 'hardware' group changes would be acted on by the server too: even if the client requested work for CPU, it wouldn't be sent if that option had been deselected in preferences.

It's that inconsistency which causes confusion such as this thread. It's easy to work round - just issue a single 'update' with No New Tasks set to transfer the settings, and then go back to normal - but it's an extra thing to remember, and seems unnecessary.
ID: 1760307 · Report as offensive
Profile Jord
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 15184
Credit: 4,362,181
RAC: 3
Netherlands
Message 1760353 - Posted: 29 Jan 2016, 13:41:25 UTC - in response to Message 1760307.  
Last modified: 29 Jan 2016, 13:42:42 UTC

The strange thing (and this is perhaps one for Jord to look into) is that I seem to remember that when this mechanism was introduced, it was stated that the 'hardware' group changes would be acted on by the server too: even if the client requested work for CPU, it wouldn't be sent if that option had been deselected in preferences.

As far as I know, that's still how it works: you change your preferences, and at the next work request of the client, the server only sends work for hardware that it sees you set in your preferences.

So even if before you had CPU work and GPU work, but change the preferences to only use GPU, the next work request the client makes, even if that's for both CPU and GPU it will only get work for the GPU sent.

I'm still busy running my cache down to be able to delete all the leftover/orphaned tasks in the directory, but then when that's done I'll test if the school venue works with 7.6.22 as it should, and test what the server will send if Use CPU isn't set, but I have added CPU applications through anonymous platform.
ID: 1760353 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14650
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1760393 - Posted: 29 Jan 2016, 15:55:15 UTC - in response to Message 1760353.  

So even if before you had CPU work and GPU work, but change the preferences to only use GPU, the next work request the client makes, even if that's for both CPU and GPU it will only get work for the GPU sent.

My feeling is that what you say is what the theoretical documentation says, but what Speedy and Rasputin have described is what happens in practice.

Easy to test, but wise to enable <sched_op_debug> logging first.
ID: 1760393 · Report as offensive
Profile Jord
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 15184
Credit: 4,362,181
RAC: 3
Netherlands
Message 1760401 - Posted: 29 Jan 2016, 16:33:11 UTC - in response to Message 1760393.  
Last modified: 29 Jan 2016, 16:33:41 UTC

I wonder here, does the server have any idea of the project preferences the user set?

So what happens when the client contacts the scheduler?
Mine says 'hi there, I'm the machine of Jord, user 41965_0dd9050d921f8f98753d812514d0586a and I am requesting work for the AMD GPU.'

I have just before this point changed my work request to that of Use CPU and Use AMD GPU. Since this information is now sent to my client on this same work request, I would think that the scheduler should tell the client, 'ah, but your boss just came by and changed the work request to include the CPU, so here, have these new preference settings and immediately take work for the AMD GPU and CPU.'

Now, I don't see in the sched_request*.xml file that the client sends information about what it asks work for in the direction of the server. But that may be because on my system I have NNT set until these last 15 stragglers are out of the way.

I do see in sched_reply*.xml that the server sends this back:
<project_preferences>
<resource_share>800</resource_share>
<no_cpu>1</no_cpu>
<no_ati>0</no_ati>
<no_cuda>1</no_cuda>
<no_intel_gpu>1</no_intel_gpu>


It's one of the reasons why I wouldn't mind looking in Speedy's sched_reply file. Even a sched_request*.xml file as well, preferably one just after changes were made to the preferences, with a work request in between, and the resulting file after the whole communication as well. But the sched_request file contains his strong authenticator key, and I do not want him to send that file to me if he doesn't trust me. He certainly shouldn't post the contents here.

(sorry, assuming Speedy is a he, excuses if not).
ID: 1760401 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14650
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1760421 - Posted: 29 Jan 2016, 17:26:20 UTC - in response to Message 1760401.  

You probably need to see four files (two request, two reply) to get the whole picture - the most interesting ones might be when the boss turns the tap off again for the CPU.

Request: xxxxx seconds CPU, yyyyy seconds GPU
Reply: Here's some work, and this is what you should ask for next time.
Request: zzzz seconds GPU.
Reply: ...

Ideally, the first reply would be for GPU only, but I suspect both will be allowed.

When allowing CPU work for the first time (your direction), the server doesn't know how many seconds xxxxx would be. Should it send one task only? One task per CPU? Assume the cache is empty? Probably best to wait until it gets an idea of 'how much?' with the second request.
ID: 1760421 · Report as offensive
Profile Jord
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 15184
Credit: 4,362,181
RAC: 3
Netherlands
Message 1760426 - Posted: 29 Jan 2016, 17:36:53 UTC - in response to Message 1760421.  

When allowing CPU work for the first time (your direction), the server doesn't know how many seconds xxxxx would be. Should it send one task only? One task per CPU? Assume the cache is empty? Probably best to wait until it gets an idea of 'how much?' with the second request.

Probably one second. The GPU cache will be filled first anyway.

Can you check in your sched_request file if BOINC sends the request for the hardware to the server? Still got 4 hours of work to go, well less if there's some error -9s in there.
ID: 1760426 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14650
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1760432 - Posted: 29 Jan 2016, 18:29:19 UTC - in response to Message 1760426.  
Last modified: 29 Jan 2016, 19:01:24 UTC

Can you check in your sched_request file if BOINC sends the request for the hardware to the server? Still got 4 hours of work to go, well less if there's some error -9s in there.

Yes, it's there, but it's dotted around all over the place. This machine has three resource types (CPU, NVidia GPU, Intel GPU), and I run different projects on the different resources - so these are assembled from three different request files. But they give you an idea what to look for.

The CPU request is right at the top of the file:

<scheduler_request>
<authenticator>hidden</authenticator>
<hostid>1291</hostid>
<rpc_seqno>12711</rpc_seqno>
<core_client_major_version>7</core_client_major_version>
<core_client_minor_version>7</core_client_minor_version>
<core_client_release>0</core_client_release>
<resource_share_fraction>0.076923</resource_share_fraction>
<rrs_fraction>0.200000</rrs_fraction>
<prrs_fraction>0.166667</prrs_fraction>
<duration_correction_factor>1.000000</duration_correction_factor>
<allow_multiple_clients>0</allow_multiple_clients>
<sandbox>0</sandbox>
<dont_send_work>0</dont_send_work>
<work_req_seconds>11889.877792</work_req_seconds>
<cpu_req_secs>11889.877792</cpu_req_secs>
<cpu_req_instances>0.000000</cpu_req_instances>
<estimated_delay>0.000000</estimated_delay>
<client_cap_plan_class>1</client_cap_plan_class>
<platform_name>windows_x86_64</platform_name>
<alt_platform>
<name>windows_intelx86</name>
</alt_platform>

(I think the separate <work_req_seconds> is a compatibility fallback for older server software)

The GPU requests are much lower down, below the global and venue preference blocks.

First, NVidia:

</host_info>
<disk_usage>
<d_boinc_used_total>4714183100.000000</d_boinc_used_total>
<d_boinc_used_project>131842638.000000</d_boinc_used_project>
<d_project_share>9911462990.769230</d_project_share>
</disk_usage>
<coprocs>
<coproc_cuda>
<count>2</count>
<name>GeForce GTX 970</name>
<available_ram>3215065088.000000</available_ram>
<have_cuda>1</have_cuda>
<have_opencl>1</have_opencl>
<req_secs>7807.363522</req_secs>
<req_instances>0.000000</req_instances>
...

then Intel:

</coproc_cuda>
<coproc_intel_gpu>
<count>1</count>
<name>Intel(R) HD Graphics 4600</name>
<available_ram>1360632218.000000</available_ram>
<have_opencl>1</have_opencl>
<req_secs>3526.191471</req_secs>
<req_instances>0.000000</req_instances>
...

Edit - perhaps I should confirm those by tying them back to the matching sched_op event log entries:

29/01/2016 17:49:58 | NumberFields@home | [sched_op] CPU work request: 11889.88 seconds; 0.00 devices
29/01/2016 17:52:36 | SETI@home | [sched_op] NVIDIA GPU work request: 7807.36 seconds; 0.00 devices
29/01/2016 11:57:39 | Einstein@Home | [sched_op] Intel GPU work request: 3526.19 seconds; 0.00 devices
ID: 1760432 · Report as offensive
Profile Jord
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 15184
Credit: 4,362,181
RAC: 3
Netherlands
Message 1760448 - Posted: 29 Jan 2016, 20:46:49 UTC
Last modified: 29 Jan 2016, 20:49:31 UTC

I have:
- set separate project preferences for school, to:
* Use CPU + Use ATI GPU.
- in local preferences, set BOINC to ask for 0 days of work + 0 extra days.
- in local preferences, set BOINC to use one core of my CPU.
- rerun Lunatics 0.44 to add CPU applications for Astropulse and Multibeam, plus ATI GPU applications for both.
- set my computer to use location school.

Separately cleaned out my Seti directory. If anyone is interested in 116 orphaned Multibeam (for testing purposes?) and 5 Astropulse, we can arrange things.. I have 7zipped them, before deleting them.

sched_request_setiathome.berkeley.edu says:
    <work_req_seconds>180.000000</work_req_seconds>
    <cpu_req_secs>0.000000</cpu_req_secs>
    <cpu_req_instances>0.000000</cpu_req_instances>

First work request after allowing new work:

29/01/2016 21:23:20 | SETI@home | work fetch resumed by user
29/01/2016 21:23:22 | SETI@home | [sched_op] Starting scheduler request
29/01/2016 21:23:22 | SETI@home | Sending scheduler request: To fetch work.
29/01/2016 21:23:22 | SETI@home | Requesting new tasks for AMD/ATI GPU
29/01/2016 21:23:22 | SETI@home | [sched_op] CPU work request: 0.00 seconds; 0.00 devices
29/01/2016 21:23:22 | SETI@home | [sched_op] AMD/ATI GPU work request: 180.00 seconds; 1.00 devices
29/01/2016 21:23:25 | SETI@home | Scheduler request completed: got 0 new tasks
29/01/2016 21:23:25 | SETI@home | [sched_op] Server version 707
29/01/2016 21:23:25 | SETI@home | No tasks sent
29/01/2016 21:23:25 | SETI@home | No tasks are available for SETI@home v7
29/01/2016 21:23:25 | SETI@home | No tasks are available for AstroPulse v7
29/01/2016 21:23:25 | SETI@home | Tasks for NVIDIA GPU are available, but your preferences are set to not accept them
29/01/2016 21:23:25 | SETI@home | Tasks for Intel GPU are available, but your preferences are set to not accept them
29/01/2016 21:23:25 | SETI@home | Project requested delay of 303 seconds
29/01/2016 21:23:25 | SETI@home | [sched_op] Deferring communication for 00:05:03
29/01/2016 21:23:25 | SETI@home | [sched_op] Reason: requested by project

Setting Network to suspend.

sched_reply_setiathome.berkeley.edu says:
<venue name="school">
<resource_share>800</resource_share>
<no_cpu>0</no_cpu>
<no_ati>0</no_ati>
<no_cuda>1</no_cuda>
<no_intel_gpu>1</no_intel_gpu>

ID: 1760448 · Report as offensive
Profile Jord
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 15184
Credit: 4,362,181
RAC: 3
Netherlands
Message 1760456 - Posted: 29 Jan 2016, 20:58:59 UTC
Last modified: 29 Jan 2016, 21:00:15 UTC

Second request for work:

29/01/2016 21:57:40 | | Resuming network activity
29/01/2016 21:57:40 | SETI@home | [sched_op] Starting scheduler request
29/01/2016 21:57:40 | SETI@home | Sending scheduler request: To fetch work.
29/01/2016 21:57:40 | SETI@home | Requesting new tasks for CPU and AMD/ATI GPU
29/01/2016 21:57:40 | SETI@home | [sched_op] CPU work request: 180.00 seconds; 1.00 devices
29/01/2016 21:57:40 | SETI@home | [sched_op] AMD/ATI GPU work request: 180.00 seconds; 1.00 devices
29/01/2016 21:57:45 | SETI@home | Scheduler request completed: got 2 new tasks
29/01/2016 21:57:45 | SETI@home | [sched_op] Server version 707
29/01/2016 21:57:45 | SETI@home | Project requested delay of 303 seconds
29/01/2016 21:57:45 | SETI@home | [task] result state=NEW for 14oc15ae.14467.8660.7.34.29_1 from handle_scheduler_reply
29/01/2016 21:57:45 | SETI@home | [task] result state=NEW for 07oc15aa.25926.24619.9.36.234.vlar_2 from handle_scheduler_reply
29/01/2016 21:57:45 | SETI@home | [sched_op] estimated total CPU task duration: 313018 seconds
29/01/2016 21:57:45 | SETI@home | [sched_op] estimated total AMD/ATI GPU task duration: 3460 seconds
29/01/2016 21:57:45 | SETI@home | [sched_op] Deferring communication for 00:05:03

Sched_request*.xml said:
    <work_req_seconds>180.000000</work_req_seconds>
    <cpu_req_secs>180.000000</cpu_req_secs>
    <cpu_req_instances>1.000000</cpu_req_instances>

ID: 1760456 · Report as offensive
Profile Jord
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 15184
Credit: 4,362,181
RAC: 3
Netherlands
Message 1760460 - Posted: 29 Jan 2016, 21:27:43 UTC
Last modified: 29 Jan 2016, 21:28:13 UTC

Setting project preferences, venue school to no longer use CPU, but continue to use the GPU.
Leave everything else as it is.

And then I had to do a rerun of CPU+GPU, because I forgot that the CPU was still saturated with the one task of work it had, and so on the next work request, BOINC only asked work for the GPU... I went for increasing my CPU to use two cores. What with the discarded 94 tasks that will eventual time out and be recorded as errors, it doesn't matter if I later abort and add a couple of tasks to that fray, does it now? ;-)

Waiting for the 5m 03s communication deferred back-off to time out.

Sched_request*.xml said:
    <work_req_seconds>17280.000000</work_req_seconds>
    <cpu_req_secs>17280.000000</cpu_req_secs>
    <cpu_req_instances>1.000000</cpu_req_instances>


Third request for work, so this is with just GPU request work set on the preferences page:
29/01/2016 22:24:59 | | Resuming network activity
29/01/2016 22:24:59 | SETI@home | [fxd] starting upload, upload_offset -1
29/01/2016 22:24:59 | SETI@home | Started upload of 13oc15ad.18830.7838.9.36.94_1_0
29/01/2016 22:24:59 | SETI@home | [file_xfer] URL: http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler
29/01/2016 22:24:59 | SETI@home | [sched_op] Starting scheduler request
29/01/2016 22:24:59 | SETI@home | Sending scheduler request: To fetch work.
29/01/2016 22:24:59 | SETI@home | Reporting 1 completed tasks
29/01/2016 22:24:59 | SETI@home | Requesting new tasks for CPU and AMD/ATI GPU
29/01/2016 22:24:59 | SETI@home | [sched_op] CPU work request: 17280.00 seconds; 1.00 devices
29/01/2016 22:24:59 | SETI@home | [sched_op] AMD/ATI GPU work request: 17280.00 seconds; 1.00 devices
29/01/2016 22:25:01 | SETI@home | [file_xfer] http op done; retval 0 (Success)
29/01/2016 22:25:01 | SETI@home | [file_xfer] parsing upload response: <data_server_reply> <status>0</status> <file_size>0</file_size></data_server_reply>
29/01/2016 22:25:01 | SETI@home | [file_xfer] parsing status: 0
29/01/2016 22:25:01 | SETI@home | [fxd] starting upload, upload_offset 0
29/01/2016 22:25:02 | SETI@home | Scheduler request completed: got 3 new tasks

Sched_reply*.xml said:
<venue name="school">
<resource_share>800</resource_share>
<no_cpu>1</no_cpu>
<no_ati>0</no_ati>
<no_cuda>1</no_cuda>
<no_intel_gpu>1</no_intel_gpu>


It's as Richard said it would be, first need to have the reply from the server back in before the next work request will follow the preferences you set.
ID: 1760460 · Report as offensive
Speedy
Volunteer tester
Avatar

Send message
Joined: 26 Jun 04
Posts: 1643
Credit: 12,921,799
RAC: 89
New Zealand
Message 1760480 - Posted: 29 Jan 2016, 22:35:30 UTC - in response to Message 1760460.  
Last modified: 29 Jan 2016, 22:38:29 UTC


It's as Richard said it would be, first need to have the reply from the server back in before the next work request will follow the preferences you set.


It's all good I am a male. Thanks for confirming this. I will have to remember to suspend work for each if you want to update my preferences.
Thinking about it I might just remove the MB 8 CPU segment of the app info file or safer yet just rerun the Lunatics installer.

But why do you have set to run a CPU app on that profile then if you do not want to receive CPU work?

I only have CPU set on my home profile is set to AP only. Hence the reason why I was asking how come I was receiving MB 8 work but we now know why that is.
Hal's response

If you like to switch CPU MB off & on then it makes sense to leave the MB CPU installed. However sometimes the server will sneak you work for other apps despite your venue settings.

Do you still require me to send you Scheduler requests?
ID: 1760480 · Report as offensive
1 · 2 · Next

Message boards : Number crunching : Possibly preferences being ignored?


 
©2024 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.