Message boards :
News :
SETI@home Version 7 has been released
Message board moderation
Previous · 1 . . . 9 · 10 · 11 · 12 · 13 · 14 · 15 . . . 19 · Next
Author | Message |
---|---|
OzzFan Send message Joined: 9 Apr 02 Posts: 15691 Credit: 84,761,841 RAC: 28 |
...but if you had work, that means the v7 application downloaded, processed work, and returned it for credit. This means your issues have little to do with the v7 rollout and more to do with how BOINC is configured on your particular machine, or a possible bug in the BOINC application framework. |
Bruce L. Stegner, Ph.D. Send message Joined: 4 Aug 99 Posts: 7 Credit: 13,622,621 RAC: 1 |
Hmm. Previously I had sufficient work unless the project was down. The system did not say I did not need work unless that was the truth. The system was able to distinguish graphics cpu tasks from others. Now I have idle engines because I have 9 or 10 tasks that are all requiring the graphics cpu. The other cpu's are idle. This is different. It appears that no distinction is made between tasks optimized for the graphics processor and tasks that do not take advantage of the graphics processor. The techniques I used to acquire tasks do not work now So yes, the system worked as long as I had enough tasks but once the tasks in queue became low this nonproductive iterative stuff took over. The infamous "Don't Loop." My installation is "vanilla" except for ample space on disks to store work. I have not tweaked anything. At least not wittingly. When I looked for what to do until ET calls the only thing I found was reset the project which is what I did. This resulted in what appears to be a partial install and no tasks. Thanks for thinking about this. Bruce |
OzzFan Send message Joined: 9 Apr 02 Posts: 15691 Credit: 84,761,841 RAC: 28 |
The system was able to distinguish graphics cpu tasks from others. All SETI@home workunits are from the same pool. It gets assigned to a particular resource based upon which resource BOINC requests work for. BOINC is designed to request work for the more powerful resource (usually your GPU) first, then request work for any slower resources. Once downloaded to your machine, BOINC does not automatically re-assign work to another resource; it remains tied to the resource for which it was requested. This design feature has prompted someone to write a program called the "BOINC rescheduler", designed specifically to allow the user to re-assign tasks from the GPU to CPU and vice versa. It sounds like for some reason BOINC is not requesting work for your CPU. My best guess is that since you reset the Project as part of your troubleshooting attempts, it is trying to fill your GPU with work first. I'd wager that if you leave it alone, the issue should resolve itself eventually. |
Bruce L. Stegner, Ph.D. Send message Joined: 4 Aug 99 Posts: 7 Credit: 13,622,621 RAC: 1 |
Excellent suggestion I will let things chill for 24 hours and see what pops out. Thanks for your thoughts Bruce |
Fred E. Send message Joined: 22 Jul 99 Posts: 768 Credit: 24,140,697 RAC: 0 |
Bruce,you shouild confirm that the cache settings in BOINC are appropriate for that version of BOINC. Should be something like Minimum work buffer of 2 or 3 days and max additional of .01 days. Those settings are under tools/computing preferences/network usage. If that doesn't do it, open a thread in Number Crunching and we'll help you troubleshoot. Another Fred Support SETI@home when you search the Web with GoodSearch or shop online with GoodShop. |
betreger Send message Joined: 29 Jun 99 Posts: 11361 Credit: 29,581,041 RAC: 66 |
So much flame because people don't understand Boinc and blame S@H instead? |
Bruce L. Stegner, Ph.D. Send message Joined: 4 Aug 99 Posts: 7 Credit: 13,622,621 RAC: 1 |
Fred Thanks for the heads up. I checked and the minimum was set to zero and the max additional was set to 0.25. I changed the minimum to 3 and minimum additional to 0.10. I think, however, that the core problem is that the project reset went belly up midway through things. There are no work units in my queue and it keeps requesting by saying it is not requesting. I will let things go overnight. If it has not self corrected I will probably uninstall and do a clean install just to try to get everything refreshed. If that doesn't work then I will post in the forum where you suggested. Thanks again, it was valuable to learn that I could tweak that buffer. Bruce |
Jeff Buck Send message Joined: 11 Feb 00 Posts: 1441 Credit: 148,764,870 RAC: 0 |
1. In task manager every 5 minutes a request is sent out that says not requesting new tasks. I replied to another user earlier in this thread about running into this problem myself and what seemed to work for me. Try using the "Read config file" command on the BOINC Manager "Advanced" menu (even if you don't have a config file). It worked on 3 of my machines, which haven't seen a recurrence of that "not requesting tasks" loop since. BTW, I suspect the few users who've actually reported this bug just represent the tip of the iceberg of those who don't yet know they've experienced it. |
Bruce L. Stegner, Ph.D. Send message Joined: 4 Aug 99 Posts: 7 Credit: 13,622,621 RAC: 1 |
Thanks, Jeff I will try that. I did find a way out of the quagmire, I think. When in doubt reboot the machine. I finally remembered to do that and whatever environmental things or cache's which were off kilter seem to have been reset. I will have to verify full functionality when the other BOINC projects clear out over night and the SAH work units start processing again. Thank you, and the others who helped me on this. It is much appreciated. Bruce |
Jeff Buck Send message Joined: 11 Feb 00 Posts: 1441 Credit: 148,764,870 RAC: 0 |
Actually, from my experience that was at least partly similar to his, the part about BOINC "not requesting tasks" every 5 minutes has everything to do with the v7 rollout AND could likely be a BOINC bug. They're not mutually exclusive. I found that the BOINC looping behavior was triggered as soon as a v7 GPU task was initiated following completion of my last v6 task on that GPU (see my Message 1375123 earlier in this thread). I seemed to be able to clear the loop, either with a manual "Update" request (on 1 machine) or with a "Read config file" command (on 3 others). I say "seemed to" because for the machine that I used the manual Update on, the bug returned this afternoon (after a 4 day hiatus). What triggered it? Well, it appears my GPU ran a v6 AP task and, as soon as that was done it went back to processing a v7 task and, sure enough, BOINC reported all completed tasks and went back to sending scheduler requests "To fetch work", "Not requesting tasks", every 5 minutes. So, to reiterate, there definitely seems to be a connection with the v7 rollout, even if the underlying bug belongs to BOINC. |
OzzFan Send message Joined: 9 Apr 02 Posts: 15691 Credit: 84,761,841 RAC: 28 |
If it were directly related, why isn't this happening on all machines then? Do we have any direct data that supports the hypothesis? Or have we simply matched a pattern that may be purely coincidental and circumstantial? BOINC is completely responsible for work fetch and application updating (as a mechanism). If it is a BOINC bug, then it is a BOINC bug regardless of the science application. The SETI@home application merely processes work and writes results to a file. Any bug with the SAH v7 app would be in the processing of the work or the writing to result files. |
Jeff Buck Send message Joined: 11 Feb 00 Posts: 1441 Credit: 148,764,870 RAC: 0 |
Thanks, Jeff Okay. I imagine that if you've already rebooted you won't need to try my suggestion anyway since, as part of it's restart, the BOINC Manager would likely have included a "Read config file" automatically. I just never got desperate enough to reboot! :) |
betreger Send message Joined: 29 Jun 99 Posts: 11361 Credit: 29,581,041 RAC: 66 |
Desperate enough to post but not enough to reboot. Rebooting is always good. |
Jeff Buck Send message Joined: 11 Feb 00 Posts: 1441 Credit: 148,764,870 RAC: 0 |
Well, I didn't say its happening on ALL machines, but there have been at least 3 other reports of the problem posted so far (2 in this forum and one in another). None of those have been analyzed to the detail that I posted, so I would suggest giving it a little time to see what else comes in. In my case, only GPU-enabled machines (all 4 of them, each with different NVIDIA card) which transition directly from a stock v6 GPU task to a stock v7 GPU task. I have 3 CPU-only machines, 2 of which made the transition seamlessly (and 1 which is still chugging away on v6). Since it appears from these forums that many forum posters (perhaps even a significant majority) were running non-stock applications, I would guess that they would have followed the oft-repeated advice to drain their queues of all v6 tasks before downloading and running v7. This would avoid the transition problem that I've seen. However, I also suspect that if the vast majority of actual SETI@home users are like me, running stock apps and allowing BOINC to automatically download and run new versions as they come down the pipe, that many will be, or already are, experiencing a similar problem. Now, having said that, I would think that it would probably also be true that users who are NOT running 24/7 may never know that its happened to them as I think that any reboot or restart of BOINC Manager may clear whatever configuration anomaly has occurred (at least until the next v6 AP to v7 SETI transition occurs, if my experience this afternoon is any indication). BTW, it would seem to me that somebody on the SETI@home staff could simply peruse the download server logs to see if these "Not requesting tasks" work fetches have proliferated. That would be a lot more productive that trying to speculate here in the forums! (Although, from what I've seen, speculation is what forum posters enjoy most.) :) |
Jeff Buck Send message Joined: 11 Feb 00 Posts: 1441 Credit: 148,764,870 RAC: 0 |
Desperate enough to post but not enough to reboot. Rebooting is always good. Actually, I didn't post the problem. I only replied to a couple of posts, after I seemed to have found a solution. As you may note from my "Posts" count, I'm really not much of a poster, but thought I could help somebody who seemed to be in a situation similar to what I experienced. |
OzzFan Send message Joined: 9 Apr 02 Posts: 15691 Credit: 84,761,841 RAC: 28 |
Since it appears from these forums that many forum posters (perhaps even a significant majority) were running non-stock applications, I would guess that they would have followed the oft-repeated advice to drain their queues of all v6 tasks before downloading and running v7. This would avoid the transition problem that I've seen. I have two machines that have remained on stock applications. Neither of these have exhibited the issues of constantly requesting more work but not getting any that you describe. I also have not rebooted either machine since the v7 application's release on Wednesday of last week. I know you didn't say it was happening to all machines, but repeatability is key to tracking down a problem. Understanding how BOINC works combined with the information you've given makes me think this is a BOINC bug exclusively, and I think the v6 AP to v7 processing is merely a coincidence, as each application does not know about the other. However, BOINC manages the switching of applications and work fetch, thus I believe is the likely culprit. BTW, it would seem to me that somebody on the SETI@home staff could simply peruse the download server logs to see if these "Not requesting tasks" work fetches have proliferated. That would be a lot more productive that trying to speculate here in the forums! (Although, from what I've seen, speculation is what forum posters enjoy most.) :) Isn't that assuming the SETI servers are recording "not requesting tasks" in their logs in the first place? (Speculation, if done properly, can help lead to solving a problem, provided one uses deductive reasoning along with speculation.) 8-) |
TRuEQ & TuVaLu Send message Joined: 4 Oct 99 Posts: 505 Credit: 69,523,653 RAC: 10 |
From Gary Charpentier: RAC is at use here and is of atleast some importance in teams and betweenteams and between users when they compare the results they have made and often the changed settings to improve/compare performance. I'd say RAC or credits are of use for the users and for the project. |
Jeff Buck Send message Joined: 11 Feb 00 Posts: 1441 Credit: 148,764,870 RAC: 0 |
I have two machines that have remained on stock applications. Neither of these have exhibited the issues of constantly requesting more work that you describe. I also have not rebooted either machine since the v7 application's release on Wednesday of last week. Both processing GPU tasks? Both NVIDIA GPUs. Okay, that's fine, then you have evidence / experience that contradicts mine. (Just a thought, are you also running BOINC 7.0.64?) Repeatability is key to tracking down a problem. Of course, which is why seeing it happen exactly the same way on all 4 of my GPU-enabled machines (with, as I said, 4 quite different GPUs and, as I hadn't previously mentioned, 2 different OS's - Win XP and Win Vista - 2 of each), leads me to what I think is a reasonable theory. I do think this is a BOINC bug, but I think the v6 AP to v7 processing is merely a coincidence, as each application does not know about each other. Ummm, perhaps. The bug may be in BOINC but it seems to me like it must be picking up certain configuration information (beyond my expertise to understand at this point) from the application and what it picks up from a newly started v7 GPU app is somehow causing a misconfiguration with whatever it was just using for the v6 GPU app. BTW, it would seem to me that somebody on the SETI@home staff could simply peruse the download server logs to see if these "Not requesting tasks" work fetches have proliferated. That would be a lot more productive that trying to speculate here in the forums! (Although, from what I've seen, speculation is what forum posters enjoy most.) :) Well, I would certainly hope that all incoming work fetch requests are being logged, but..... Ah, yes, I think your phrase, if done properly, is the key. I'm not sure I've seen a lot of that since I've been lurking here! |
Jeff Buck Send message Joined: 11 Feb 00 Posts: 1441 Credit: 148,764,870 RAC: 0 |
As a follow-up, here's a portion of one of my logs that shows the transition from the final cuda23 task to the first cuda32 task. As you can see, within 3 seconds of uploading the cuda23 task, the repeating sequence started. This was consistent across all 4 of my GPU-enabled machines. I've also included enough to show that the 5 minute communications backoff loop was periodically superseded by a longer project backoff, but then the 5 minute loop returned. 5/31/2013 10:30:23 AM | SETI@home | Starting task 23jn12ab.24163.21032.12.11.50_1 using setiathome_enhanced version 609 (cuda23) in slot 2 5/31/2013 10:30:25 AM | SETI@home | Started upload of 23oc12ac.25717.18472.12.11.50_0_0 5/31/2013 10:30:28 AM | SETI@home | Finished upload of 23oc12ac.25717.18472.12.11.50_0_0 5/31/2013 11:31:14 AM | SETI@home | Computation for task 23jn12ab.24163.21032.12.11.50_1 finished 5/31/2013 11:31:14 AM | SETI@home | Starting task 23oc12ac.25646.13973.15.12.45_0 using setiathome_v7 version 700 (cuda32) in slot 2 5/31/2013 11:31:18 AM | SETI@home | Started upload of 23jn12ab.24163.21032.12.11.50_1_0 5/31/2013 11:31:25 AM | SETI@home | Finished upload of 23jn12ab.24163.21032.12.11.50_1_0 5/31/2013 11:31:28 AM | SETI@home | Sending scheduler request: To fetch work. 5/31/2013 11:31:28 AM | SETI@home | Reporting 2 completed tasks 5/31/2013 11:31:28 AM | SETI@home | Not requesting tasks 5/31/2013 11:31:30 AM | SETI@home | Scheduler request completed 5/31/2013 11:33:26 AM | SETI@home | Computation for task 26mr10ab.24819.17826.5.11.138_0 finished 5/31/2013 11:33:26 AM | SETI@home | Starting task 23oc12ac.25646.13973.15.12.40_0 using setiathome_v7 version 700 in slot 1 5/31/2013 11:33:29 AM | SETI@home | Started upload of 26mr10ab.24819.17826.5.11.138_0_0 5/31/2013 11:33:32 AM | SETI@home | Finished upload of 26mr10ab.24819.17826.5.11.138_0_0 5/31/2013 11:36:35 AM | SETI@home | Sending scheduler request: To fetch work. 5/31/2013 11:36:35 AM | SETI@home | Reporting 1 completed tasks 5/31/2013 11:36:35 AM | SETI@home | Not requesting tasks 5/31/2013 11:36:37 AM | SETI@home | Scheduler request completed 5/31/2013 1:28:09 PM | SETI@home | Sending scheduler request: To fetch work. 5/31/2013 1:28:09 PM | SETI@home | Not requesting tasks 5/31/2013 1:28:11 PM | SETI@home | Scheduler request completed 5/31/2013 1:33:15 PM | SETI@home | Sending scheduler request: To fetch work. 5/31/2013 1:33:15 PM | SETI@home | Not requesting tasks 5/31/2013 1:33:19 PM | SETI@home | Scheduler request completed 5/31/2013 1:38:23 PM | SETI@home | Sending scheduler request: To fetch work. 5/31/2013 1:38:23 PM | SETI@home | Not requesting tasks 5/31/2013 1:38:26 PM | SETI@home | Scheduler request completed 5/31/2013 1:43:30 PM | SETI@home | Sending scheduler request: To fetch work. 5/31/2013 1:43:30 PM | SETI@home | Not requesting tasks 5/31/2013 1:43:33 PM | SETI@home | Scheduler request completed 5/31/2013 1:48:37 PM | SETI@home | Sending scheduler request: To fetch work. 5/31/2013 1:48:37 PM | SETI@home | Not requesting tasks 5/31/2013 1:48:40 PM | SETI@home | Scheduler request completed 5/31/2013 1:53:45 PM | SETI@home | Sending scheduler request: To fetch work. 5/31/2013 1:53:45 PM | SETI@home | Not requesting tasks 5/31/2013 1:53:48 PM | SETI@home | Scheduler request completed 5/31/2013 1:58:52 PM | SETI@home | Sending scheduler request: To fetch work. 5/31/2013 1:58:52 PM | SETI@home | Not requesting tasks 5/31/2013 1:58:55 PM | SETI@home | Scheduler request completed 5/31/2013 2:30:19 PM | SETI@home | Sending scheduler request: To fetch work. 5/31/2013 2:30:19 PM | SETI@home | Not requesting tasks 5/31/2013 2:30:21 PM | SETI@home | Scheduler request completed 5/31/2013 2:35:26 PM | SETI@home | Sending scheduler request: To fetch work. 5/31/2013 2:35:26 PM | SETI@home | Not requesting tasks 5/31/2013 2:35:28 PM | SETI@home | Scheduler request completed I allowed this to continue for several hours, to see if it would clear itself, but it never did until I used the "Read config file" command in BOINC. I think this machine will complete a v6 AP GPU task overnight, so it will be interesting to see if the loop returns tomorrow. Yawn. |
Gundolf Jahn Send message Joined: 19 Sep 00 Posts: 3184 Credit: 446,358 RAC: 0 |
I have two machines that have remained on stock applications. Neither of these have exhibited the issues of constantly requesting more work but not getting any that you describe. The problem is not that they aren't getting any work, but that they are sending scheduler requests to fetch work and not requesting tasks. Gruß, Gundolf |
©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.