Apparently not a single person expected the Server to change the way it did. Unexpected changes are usually undesired, especially when it causes problems that force the average user to make your 'couple of clicks'. Usually the average user is unaware of those 'couple of clicks'. That doesn't seem to bother you though. So far, you are the only one that thinks the change is fine. Claggy's original response is typical.

I suspect your posts have absolutely one goal, and it doesn't advance this topic one bit.

Apparently not a single person expected the Server to change the way it did. Unexpected changes are usually undesired, especially when it causes problems that force the average user to make your 'couple of clicks'. Usually the average user is unaware of those 'couple of clicks'. That doesn't seem to bother you though. So far, you are the only one that thinks the change is fine. Claggy's original response is typical.

I suspect your posts have absolutely one goal, and it doesn't advance this topic one bit.

The "average user" is probably unaware of any of the issues we're discussing here. They don't build hosts with multiple GPUs, they don't run 10-day caches, they don't restrict themselves to just one project, they don't get upset if their personal computer isn't doing scientific research at 100% utilisation 168 hours a week.

Basically, BOINC works fine. If you push it to the extreme, the weaknesses show - and I had to turn my knobs way past their usual maximum in order to trigger an out-of-band response like the one you were reporting.

I don't mind doing that - it makes for an interesting hobby - but don't try to pretend that what you're doing is anything other that extreme tinkering.

Apparently not a single person expected the Server to change the way it did. Unexpected changes are usually undesired, especially when it causes problems that force the average user to make your 'couple of clicks'. Usually the average user is unaware of those 'couple of clicks'. That doesn't seem to bother you though. So far, you are the only one that thinks the change is fine. Claggy's original response is typical.

I suspect your posts have absolutely one goal, and it doesn't advance this topic one bit.

The "average user" is probably unaware of any of the issues we're discussing here. They don't build hosts with multiple GPUs, they don't run 10-day caches, they don't restrict themselves to just one project, they don't get upset if their personal computer isn't doing scientific research at 100% utilisation 168 hours a week.

Basically, BOINC works fine. If you push it to the extreme, the weaknesses show - and I had to turn my knobs way past their usual maximum in order to trigger an out-of-band response like the one you were reporting.

I don't mind doing that - it makes for an interesting hobby - but don't try to pretend that what you're doing is anything other that extreme tinkering.

What about Cherokee150, http://setiathome.berkeley.edu/forum_thread.php?id=75810&postid=1592225, merle, http://setiathome.berkeley.edu/forum_thread.php?id=75945&postid=1590663#1590663 and others?

Is what they are doing extreme tinkering?

Another change that occurred with the Server. Use to be just about all the re-sends went to my GPUs. Makes sense, I have 3 GPUs that average around 30 minutes per AP and only run 2 CPU tasks that average about 9 hours. Now for some reason, just about All the re-sends are sent to my 2 overworked CPUs. That doesn't make much sense when there are 3 hungry GPUs than run dry much quicker than the CPUs. This happened the same time the Server decided to start filling the CPU cache First. My guess is the two are related. Hope that helps.

Again, nothing has changed on this end but you can see it here; http://setiathome.berkeley.edu/results.php?hostid=6796479

So set your work cache to about 2.25 days. You will get the 100 tasks for the gpu's, and just a few for the cpu's.

Is what they are doing extreme tinkering?

Egged on by people like you on this message board, yes.

Another change that occurred with the Server. Use to be just about all the re-sends went to my GPUs. Makes sense, I have 3 GPUs that average around 30 minutes per AP and only run 2 CPU tasks that average about 9 hours. Now for some reason, just about All the re-sends are sent to my 2 overworked CPUs. That doesn't make much sense when there are 3 hungry GPUs than run dry much quicker than the CPUs. This happened the same time the Server decided to start filling the CPU cache First. My guess is the two are related. Hope that helps.

Again, nothing has changed on this end but you can see it here; http://setiathome.berkeley.edu/results.php?hostid=6796479

So set your work cache to about 2.25 days. You will get the 100 tasks for the gpu's, and just a few for the cpu's.

If I did that the machine would run out of work in about 2.5 days instead of about 3.5 days. I can compensate.

I thought my Observation might help someone discover why the server is sending work to the CPUs first. Obviously the same setting that is now sending the re-sends to the CPUs is the same one filling the CPU cache first. It should be anyway. I just delivered a possible location to investigate.

Is what they are doing extreme tinkering?

Egged on by people like you on this message board, yes.

That's a very interesting response.

Hmmmm. Yes, that IS an interesting response since the BOINC project has seen fit to support "extreme tinkering" (crunching) by exposing all the controls the way it has. But ... don't be too hard on Richard. I can see he is a reasonable person.

Richard, please remember to consider this: it is the "extreme" crunchers who often uncover and assist in the correction of problems/weaknesses with BOINC. Sending work to the CPU side in preference to the GPU side would NOT be supporting them nicely. After all, some of us have (and are) spending lots of money to support BOINC/SETI.

If there is something I can do to help identify the cause, please let me know.

Out of curiosity, does anyone know what proportion of the SETI work gets done by the "extreme" crunchers?

I know Richard means well, BTW, did you know we are on the same Team? Go RL!

But, I just have to comment about how myself and Cherokee weren't doing anything extreme. He was just trying to convert from v6 to v7. I was just trying to compare Ubuntu & Vista, and we both ran into the same basic problem. The fact that Richard had to jump through all those hoops to get the same response we got by just launching the program should be noted. He did do a lot of work on that other thread, I was impressed.

I really didn't have a clue about why the server changed earlier, but, when I saw all those re-sends going to the CPUs I had a brainstorm. I still think it is a major clue about where to look.

<nods head vigorously>

So I setup a new instance of BOINC using 7.2.42. I attached to SETI@home & here are the results of the work requests

27-Oct-2014 21:49:17 [http://setiathome.berkeley.edu/] Master file download succeeded
27-Oct-2014 21:49:22 [http://setiathome.berkeley.edu/] Sending scheduler request: Project initialization.
27-Oct-2014 21:49:22 [http://setiathome.berkeley.edu/] Requesting new tasks for CPU and intel_gpu
27-Oct-2014 21:49:24 [SETI@home] Scheduler request completed: got 1 new tasks
27-Oct-2014 21:49:24 [SETI@home] General prefs: from SETI@home (last modified 27-Oct-2014 21:46:53)
27-Oct-2014 21:49:24 [SETI@home] Host location: none
27-Oct-2014 21:49:24 [SETI@home] General prefs: using your defaults

Received 1 task for CPU.

27-Oct-2014 21:55:46 [SETI@home] update requested by user
27-Oct-2014 21:55:49 [SETI@home] Sending scheduler request: Requested by user.
27-Oct-2014 21:55:49 [SETI@home] Requesting new tasks for CPU and intel_gpu
27-Oct-2014 21:55:52 [SETI@home] Scheduler request completed: got 67 new tasks

Received 67 tasks for iGPU .

27-Oct-2014 22:03:11 [SETI@home] update requested by user
27-Oct-2014 22:03:13 [SETI@home] Sending scheduler request: Requested by user.
27-Oct-2014 22:03:13 [SETI@home] Requesting new tasks for CPU and intel_gpu
27-Oct-2014 22:03:17 [SETI@home] Scheduler request completed: got 132 new tasks

Received 132 tasks for CPU & iGPU filling the host queue to its limit of 200 tasks.

The task list shows matches times for the work requests with my timezone of UTC -4(US EDT) this time of year.

The venue settings are for a cache of 10 & 10 (20 day cache) & MB only for this test. I would have set it up to request AP work, but knowing the AP coffers are dry that would have not been very fruitful.

I can repeat this once we have AP to spare again. However, I do suspect that it will take more than 3 request for work to fill the host queue to the limit with AP. Looking in my logs the most AP I have had in one request looks to be 7 in the past several weeks.

---

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

...I would have set it up to request AP work, but knowing the AP coffers are dry that would have not been very fruitful.

I can repeat this once we have AP to spare again. However, I do suspect that it will take more than 3 request for work to fill the host queue to the limit with AP. Looking in my logs the most AP I have had in one request looks to be 7 in the past several weeks.

Yes, MBs are not APs. I was going to ask, then decided to check myself. I just checked two of your Hosts. One only had a couple resends, the other looked just like my Host, http://setiathome.berkeley.edu/results.php?hostid=5255585
All the resends since the well ran dry went to the CPU. I'm going to check a few others. Well, checking other hosts is too much work. Apparently quite a few had full CPU caches using MBs. My CPU cache has room for resends, the GPU cache has much more room though. Anyone else have room in both caches and receiving just CPU AP resends?

...I would have set it up to request AP work, but knowing the AP coffers are dry that would have not been very fruitful.

I can repeat this once we have AP to spare again. However, I do suspect that it will take more than 3 request for work to fill the host queue to the limit with AP. Looking in my logs the most AP I have had in one request looks to be 7 in the past several weeks.

Yes, MBs are not APs. I was going to ask, then decided to check myself. I just checked two of your Hosts. One only had a couple resends, the other looked just like my Host, http://setiathome.berkeley.edu/results.php?hostid=5255585
All the resends since the well ran dry went to the CPU. I'm going to check a few others. Well, checking other hosts is too much work. Apparently quite a few had full CPU caches using MBs. My CPU cache has room for resends, the GPU cache has much more room though. Anyone else have room in both caches and receiving just CPU AP resends?

Only 3 of my hosts are configured for CPU & GPU AP only. Hosts 5837483, 5255585, & 7324426. I was going to do some benchmarking on host 7395996, but then we switched to AP v7. On my notebook 5838375. I can run CPU tasks or GPU tasks, but not both due to overheating. Maybe if I stick it outside in the winter...
Everything else runs CPU only for MB or AP. With the exception of 6727898. Which runs CPU & GPU MB with an old NV 8500 GT.

Host 5837483 has has surprisingly bad luck getting any resends. While 5255585 has been filling up. With AP luck of the draw is a wildcard in the calculation as well.

---

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

Anyone else have room in both caches and receiving just CPU AP resends?

My hosts are all mixed MB and AP. It's been over 24 hours since I got an AP resend but it, and virtually all previous resends have gone to the GPUs. The last AP resend to go to a CPU was back on October 19 on my #2 cruncher. In fact, less than 2% of the AP v7 tasks received by all my hosts have gone to CPUs.

Well, the Well went dry about 24 hours ago. Until then most people had full caches. Apparently Cherokee150 changed his preferences to allow CPU APs a little while ago, he must have gotten tired of waiting for a GPU AP. He got a resend, look where it went, http://setiathome.berkeley.edu/results.php?hostid=3324167

That host still hasn't received the first GPU APv7.

Another change that occurred with the Server. Use to be just about all the re-sends went to my GPUs. Makes sense, I have 3 GPUs that average around 30 minutes per AP and only run 2 CPU tasks that average about 9 hours. Now for some reason, just about All the re-sends are sent to my 2 overworked CPUs. That doesn't make much sense when there are 3 hungry GPUs than run dry much quicker than the CPUs. This happened the same time the Server decided to start filling the CPU cache First. My guess is the two are related. Hope that helps.

Again, nothing has changed on this end but you can see it here; http://setiathome.berkeley.edu/results.php?hostid=6796479

So set your work cache to about 2.25 days. You will get the 100 tasks for the gpu's, and just a few for the cpu's.

If I did that the machine would run out of work in about 2.5 days instead of about 3.5 days. I can compensate.

I thought my Observation might help someone discover why the server is sending work to the CPUs first. Obviously the same setting that is now sending the re-sends to the CPUs is the same one filling the CPU cache first. It should be anyway. I just delivered a possible location to investigate.

The most powerful part of the computer, the graphics card, will be out of AP work in about two days, so why ask for more than can be delivered.

Apparently not a single person expected the Server to change the way it did. Unexpected changes are usually undesired, especially when it causes problems that force the average user to make your 'couple of clicks'. Usually the average user is unaware of those 'couple of clicks'. That doesn't seem to bother you though. So far, you are the only one that thinks the change is fine. Claggy's original response is typical.

I suspect your posts have absolutely one goal, and it doesn't advance this topic one bit.

And your posts just seem to be from a credit hungry person so there you go. ;-)

Cheers.

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.

---

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

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.

But I imagine that it was people with fast CPU's and slow GPU's that got the priority changed and they make up the majority of users out there, us 1% people are just a drop in the ocean compared to them. ;-)

Cheers.

OK, I think I've just disproved my own theory.

28/10/2014 09:17:20 | SETI@home | This computer has reached a limit on tasks in progress
28/10/2014 09:28:29 | SETI@home | Sending scheduler request: To fetch work.
28/10/2014 09:28:29 | SETI@home | Requesting new tasks for CPU and Intel GPU
28/10/2014 09:28:29 | SETI@home | [sched_op] CPU work request: 965866.76 seconds; 0.00 devices
28/10/2014 09:28:29 | SETI@home | [sched_op] Intel GPU work request: 403871.77 seconds; 0.00 devices
28/10/2014 09:28:33 | SETI@home | Scheduler request completed: got 1 new tasks
28/10/2014 09:28:33 | SETI@home | [sched_op] estimated total Intel GPU task duration: 10445 seconds
28/10/2014 09:28:35 | SETI@home | Started download of ap_06se14aa_B5_P1_00089_20141020_25712.wu
28/10/2014 09:28:56 | SETI@home | Finished download of ap_06se14aa_B5_P1_00089_20141020_25712.wu

I'm still running MB on CPU, AP on iGPU - so I can quickly confirm how many of each are in progress with the task list filters. Currently, I'm bumping along at the top limit of 100 for CPU, replacing like-for-like as each task finishes.

But the server does NOT bale out of a GPU request if the CPU is limited. Next theory, please?

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.