Message boards :
Number crunching :
AP V7
Message board moderation
Previous · 1 . . . 15 · 16 · 17 · 18 · 19 · 20 · Next
Author | Message |
---|---|
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
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. |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14650 Credit: 200,643,578 RAC: 874 |
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. 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. |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
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. 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? |
W-K 666 Send message Joined: 18 May 99 Posts: 19064 Credit: 40,757,560 RAC: 67 |
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. 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. |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14650 Credit: 200,643,578 RAC: 874 |
Is what they are doing extreme tinkering? Egged on by people like you on this message board, yes. |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
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. 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. |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
Is what they are doing extreme tinkering? That's a very interesting response. |
Darrell Wilcox Send message Joined: 11 Nov 99 Posts: 303 Credit: 180,954,940 RAC: 118 |
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? |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
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> |
HAL9000 Send message Joined: 11 Sep 99 Posts: 6534 Credit: 196,805,888 RAC: 57 |
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 succeededReceived 1 task for CPU. 27-Oct-2014 21:55:46 [SETI@home] update requested by userReceived 67 tasks for iGPU . 27-Oct-2014 22:03:11 [SETI@home] update requested by userReceived 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[ |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
...I would have set it up to request AP work, but knowing the AP coffers are dry that would have not been very fruitful. 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? |
HAL9000 Send message Joined: 11 Sep 99 Posts: 6534 Credit: 196,805,888 RAC: 57 |
...I would have set it up to request AP work, but knowing the AP coffers are dry that would have not been very fruitful. 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[ |
Jeff Buck Send message Joined: 11 Feb 00 Posts: 1441 Credit: 148,764,870 RAC: 0 |
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. |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
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. |
W-K 666 Send message Joined: 18 May 99 Posts: 19064 Credit: 40,757,560 RAC: 67 |
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. 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. |
Wiggo Send message Joined: 24 Jan 00 Posts: 34758 Credit: 261,360,520 RAC: 489 |
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. And your posts just seem to be from a credit hungry person so there you go. ;-) Cheers. |
petri33 Send message Joined: 6 Jun 02 Posts: 1668 Credit: 623,086,772 RAC: 156 |
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 |
Wiggo Send message Joined: 24 Jan 00 Posts: 34758 Credit: 261,360,520 RAC: 489 |
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. |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14650 Credit: 200,643,578 RAC: 874 |
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 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? |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
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. |
©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.