SETI@home Version 7 has been released

Message boards : News : SETI@home Version 7 has been released
Message board moderation

To post messages, you must log in.

Previous · 1 . . . 10 · 11 · 12 · 13 · 14 · 15 · 16 . . . 20 · Next

AuthorMessage
Profile Jeff Buck Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester

Send message
Joined: 11 Feb 00
Posts: 1441
Credit: 148,764,870
RAC: 0
United States
Message 1375716 - Posted: 3 Jun 2013, 2:59:21 UTC - in response to Message 1375643.  


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.

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.
ID: 1375716 · Report as offensive
OzzFan Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 9 Apr 02
Posts: 15682
Credit: 82,705,615
RAC: 38,644
United States
Message 1375718 - Posted: 3 Jun 2013, 3:03:22 UTC - in response to Message 1375716.  
Last modified: 3 Jun 2013, 3:34:15 UTC


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.

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.

So, to reiterate, there definitely seems to be a connection with the v7 rollout, even if the underlying bug belongs to BOINC.


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.
ID: 1375718 · Report as offensive
Profile Jeff Buck Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester

Send message
Joined: 11 Feb 00
Posts: 1441
Credit: 148,764,870
RAC: 0
United States
Message 1375722 - Posted: 3 Jun 2013, 3:11:29 UTC - in response to Message 1375706.  

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

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! :)
ID: 1375722 · Report as offensive
Profile betreger
Avatar

Send message
Joined: 29 Jun 99
Posts: 9549
Credit: 26,016,291
RAC: 22,393
United States
Message 1375730 - Posted: 3 Jun 2013, 3:34:55 UTC - in response to Message 1375722.  
Last modified: 3 Jun 2013, 3:36:15 UTC

Desperate enough to post but not enough to reboot. Rebooting is always good.
ID: 1375730 · Report as offensive
Profile Jeff Buck Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester

Send message
Joined: 11 Feb 00
Posts: 1441
Credit: 148,764,870
RAC: 0
United States
Message 1375732 - Posted: 3 Jun 2013, 3:40:15 UTC - in response to Message 1375718.  


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.

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.

So, to reiterate, there definitely seems to be a connection with the v7 rollout, even if the underlying bug belongs to BOINC.


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?

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.) :)

ID: 1375732 · Report as offensive
Profile Jeff Buck Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester

Send message
Joined: 11 Feb 00
Posts: 1441
Credit: 148,764,870
RAC: 0
United States
Message 1375734 - Posted: 3 Jun 2013, 3:43:26 UTC - in response to Message 1375730.  

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.
ID: 1375734 · Report as offensive
OzzFan Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 9 Apr 02
Posts: 15682
Credit: 82,705,615
RAC: 38,644
United States
Message 1375735 - Posted: 3 Jun 2013, 3:54:35 UTC - in response to Message 1375732.  
Last modified: 3 Jun 2013, 4:14:59 UTC

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).


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-)
ID: 1375735 · Report as offensive
Profile TRuEQ & TuVaLu
Volunteer tester
Avatar

Send message
Joined: 4 Oct 99
Posts: 504
Credit: 65,623,203
RAC: 16,873
Sweden
Message 1375741 - Posted: 3 Jun 2013, 4:21:06 UTC - in response to Message 1375604.  
Last modified: 3 Jun 2013, 4:21:43 UTC

From Gary Charpentier:


[...]If RAC is all you care about, there are other projects [that] pay far more. Switch today!


+1000 Too many crunchers here are worried about RAC. It's not a race, folks. The project is what matters, not inflating your ego by showing up in the top 10 of some list...Let go of your ego; see past that and you'll realize that we're all on the same team. No one is any better than anyone else.

Deep breaths, people. In a little while everything will be hunky-dory. In the meantime: deep breaths.

Back to the topic. v7 seems to be running pretty good on my end. Still a little confused about two different types of GPU tasks being crunched on my machine, but I know it's somehow a planned thing. Slower to crunch stuff than before, but also a planned thing I think. All in all: I gotz work so I'm happy!


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.
ID: 1375741 · Report as offensive
Profile Jeff Buck Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester

Send message
Joined: 11 Feb 00
Posts: 1441
Credit: 148,764,870
RAC: 0
United States
Message 1375742 - Posted: 3 Jun 2013, 4:21:46 UTC - in response to Message 1375735.  

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.) :)


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-)

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!
ID: 1375742 · Report as offensive
Profile Jeff Buck Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester

Send message
Joined: 11 Feb 00
Posts: 1441
Credit: 148,764,870
RAC: 0
United States
Message 1375756 - Posted: 3 Jun 2013, 5:04:15 UTC - in response to Message 1375735.  
Last modified: 3 Jun 2013, 5:12:36 UTC

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.
ID: 1375756 · Report as offensive
Profile Gundolf Jahn

Send message
Joined: 19 Sep 00
Posts: 3184
Credit: 446,358
RAC: 0
Germany
Message 1375782 - Posted: 3 Jun 2013, 6:25:25 UTC - in response to Message 1375735.  

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
ID: 1375782 · Report as offensive
Profile William
Volunteer tester
Avatar

Send message
Joined: 14 Feb 13
Posts: 2037
Credit: 17,689,662
RAC: 0
Message 1375855 - Posted: 3 Jun 2013, 9:36:35 UTC - in response to Message 1375782.  

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

Please head over to NC and start a dedicated thread.
The is a very high overlap between the Lunatics team (especially the installer crew) and the people commited to chasing boinc bugs and generally manning the help desk.
While we are busy trying to get an installer out we can't chase boinc bugs.
Please open a dedicated NC thread for any boinc based problems and we'll look into it when we can remove the asbestos suits.
A person who won't read has no advantage over one who can't read. (Mark Twain)
ID: 1375855 · Report as offensive
Profile tullio
Volunteer tester

Send message
Joined: 9 Apr 04
Posts: 7741
Credit: 2,841,000
RAC: 6,623
Italy
Message 1375895 - Posted: 3 Jun 2013, 11:37:10 UTC

Much ado about nothing. I am running SETI@home v7 on a Linux box, Astropulse V6 by Lunatics on another Linux box and SETI@home V6.03 by Dotsch on a Solaris Virtual Machine on the second Linux box, which houses also a BOINC_VM Virtual Machine. The two don't interfere except at start time, when I have to suspend Solaris to let BOINC_VM start, for unknown reasons.
Tullio
ID: 1375895 · Report as offensive
OzzFan Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 9 Apr 02
Posts: 15682
Credit: 82,705,615
RAC: 38,644
United States
Message 1375897 - Posted: 3 Jun 2013, 11:43:48 UTC - in response to Message 1375742.  

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?)


One is not processing GPU tasks and is on BOINC v7.0.64. The other is processing nVidia GPU tasks and is on BOINC v7.0.28. Both machines are running Windows 7 x64. This seems to support the idea that this bug is unique to v7.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.


So different (nVidia?) GPUs, different OSes, but all using the same BOINC version?

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.


The individual science apps don't leave configuration information behind. In fact, any command line switches or configuration is handed to the science application via BOINC, which brings us right back to BOINC as the likely problem.

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-)

Well, I would certainly hope that all incoming work fetch requests are being logged, but.....


At over 500,000 computers, I don't know if I'd want to keep all of that logged on my servers if it were me. That should be logged on the client if anything, but I admit that I don't know the extent of the logging on the SETI@home servers.
ID: 1375897 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 13195
Credit: 154,685,184
RAC: 198,069
United Kingdom
Message 1375914 - Posted: 3 Jun 2013, 12:35:46 UTC - in response to Message 1375897.  

At over 500,000 computers, I don't know if I'd want to keep all of that logged on my servers if it were me. That should be logged on the client if anything, but I admit that I don't know the extent of the logging on the SETI@home servers.

All server requests are logged, or are capable of being logged, on the server by BOINC. You can actually see the logs live on Einstein's and Albert's web pages - for the most recent single request only. David sometimes requests that an observation (and this would be a case in point) be repeated using the SETI project, because this is the only one where he routinely has direct access to the server logs. I don't think they're kept for very long, though.
ID: 1375914 · Report as offensive
OzzFan Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 9 Apr 02
Posts: 15682
Credit: 82,705,615
RAC: 38,644
United States
Message 1375931 - Posted: 3 Jun 2013, 13:50:58 UTC - in response to Message 1375914.  

Thanks for clearing that up Richard. With that information, I suppose it would be easy for the Project Admins to look up the amount of work requests by clients to see how many of them are not getting work when requested to see if this is a widespread problem.
ID: 1375931 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 13195
Credit: 154,685,184
RAC: 198,069
United Kingdom
Message 1375944 - Posted: 3 Jun 2013, 15:15:18 UTC

Please see the Announcement in number crunching:

Updated Installers, v0.41 for Windows
Available now


These support the new SETI@home Version 7 tasks we've been discussing in this thread.
ID: 1375944 · Report as offensive
Profile Jeff Buck Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester

Send message
Joined: 11 Feb 00
Posts: 1441
Credit: 148,764,870
RAC: 0
United States
Message 1375957 - Posted: 3 Jun 2013, 15:56:21 UTC - in response to Message 1375897.  

It's morning again and I guess I'll squeeze in one last post on this "fetch work / not requesting tasks" issue and then it looks like I should make way for installer-related posts.

One is not processing GPU tasks and is on BOINC v7.0.64. The other is processing nVidia GPU tasks and is on BOINC v7.0.28. Both machines are running Windows 7 x64. This seems to support the idea that this bug is unique to v7.0.64.

Sounds reasonable.

So different (nVidia?) GPUs, different OSes, but all using the same BOINC version?

Yes, a GTX 550 ti, a GT 640, an 8600 GT, and an old GeForce 405; basically whatever the MB and power supply in each box would support. All are on BOINC v7.0.64 and all with the latest NVIDIA driver (314.22).

At over 500,000 computers, I don't know if I'd want to keep all of that logged on my servers if it were me. That should be logged on the client if anything, but I admit that I don't know the extent of the logging on the SETI@home servers.

Actually, regardless of the number of connected computers, I'd think it would be irresponsible to not have at least some level of logging in place. In any event, I see from a later post that there might be something available for the Admins to look at, if they choose to.

And from my own final post last night:
I think this machine will complete a v6 AP GPU task overnight, so it will be interesting to see if the loop returns tomorrow.

Yes, the v6 AP task completed and NO, the loop did not start back up. So, my next observable milestone will probably be tonight when the machine which did resume looping runs another AP GPU task.

As far as opening a thread in another forum goes, I'll leave that to anyone who's still actively experiencing the problem. I just started posting here in an attempt to be helpful to a couple of users who had seemed to experience the problem after I had seemingly found a way to get past it.
ID: 1375957 · Report as offensive
OzzFan Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 9 Apr 02
Posts: 15682
Credit: 82,705,615
RAC: 38,644
United States
Message 1375962 - Posted: 3 Jun 2013, 16:05:34 UTC - in response to Message 1375957.  

At over 500,000 computers, I don't know if I'd want to keep all of that logged on my servers if it were me. That should be logged on the client if anything, but I admit that I don't know the extent of the logging on the SETI@home servers.

Actually, regardless of the number of connected computers, I'd think it would be irresponsible to not have at least some level of logging in place. In any event, I see from a later post that there might be something available for the Admins to look at, if they choose to.


Agreed that it would be irresponsible to not have at least some level of logging in place. I don't know that I would log all work requests though as I would think most of that information to be largely irrelevant to the science, and would consume too much storage space for what little insight it would provide. For reference, my company has 6,000+ computers and the server logs consume well over a Gigabyte per day.
ID: 1375962 · Report as offensive
Profile Phil
Volunteer tester
Avatar

Send message
Joined: 19 Jun 99
Posts: 110
Credit: 4,545,588
RAC: 7
United Kingdom
Message 1375995 - Posted: 3 Jun 2013, 16:49:17 UTC - in response to Message 1374931.  

After I enabled V7 I could not even navigate any of my 3 browsers to Berkely university websites... much less the SETI@home. I had to format my drive and re-install windows because I even have a hunch about users in here now and their custom worms

Terrible, aint it. My AVG said there is some woodworm infection in the basement, so I'm even having to buy a new house.
ID: 1375995 · Report as offensive
Previous · 1 . . . 10 · 11 · 12 · 13 · 14 · 15 · 16 . . . 20 · Next

Message boards : News : SETI@home Version 7 has been released


 
©2019 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.