| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Support
Forum: BOINC Agent Support
Thread: WCG version of BOINC supporting cuda |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 47
|
|
| Author |
|
|
Ingleside
Veteran Cruncher Norway Joined: Nov 19, 2005 Post Count: 974 Status: Offline Project Badges: 
|
I completely disagree. If you want HELP, it is your best interest to use supported software. If you are not going to bother the WCG staff and CAs, feel free to do as you like. A quick look on Project Credit Comparison shows of WCG's currently... 198034 active computers, so is 18222 of these also actively running SETI@home, meaning 9.2%. According to SETI@home's List of recently connected client types roughly 0.1% of connections is from v6.2.28. This means 9.0% of WCG-computers runs SETI@home and also don't run v6.2.28. How many is active in other projects and not SETI@home is more difficult to know, but would guess atleast 10% of active WCG-computers runs multi-project and non-v6.2.28. For multi-project, v6.2.28 is often not an option, either due to lacking CUDA-support, or due to being 32-bit-only. (According to connection-statistics, roughly 30% of connections from SETI@home-windows-clients is from 64-bit BOINC-clients) How many computers that is only active in WCG also don't run v6.2.28 is unknown, someone from WCG can answer this if they wants... But regardless of if only the 10% multi-project-computers runs other BOINC-clients, it's still my opinion that it's in WCG's best interest to also try supporting these. If someone asks "how to cache more work", an answer like "your ver-x.y.z is unsupported, you'll need to change to v6.2.28 before I'm answering the exact same question" doesn't make any sence to me.  "I make so many mistakes. But then just think of all the mistakes I don't make, although I might." |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
Think you've typed / or copied that line now multiple times Ingleside. There's one who's rather direct and consistent at that afaik.
----------------------------------------et al, My declared position edge ways in, announced stable versions. Those that come from other projects know no better and sure as heck would we like these volunteers to contribute a good portion of their CPU time at WCG! Now if a known alpha list tester who comes here with a solidly documented issue, not the 'duh, my job crashed', I'd be stretching over to help and find if it's the client or the science. I'll fetch the client if need be and test it myself, which I do all the time. Only if it's a mature alpha though, really beta, not 6.5.0-10 or 6.6.1-10... any of the lowish point releases. We've learned by now that anything before .20 is not worth our time in a live environment. The recommended 6.6.20 had a lifespan 8 days. Telling enough I'd say when seeing that red line BOINC log message of 'there's a new version' better be approached by production crunchers with 'let's wait and see how this pans out'. For those At The Hop by Danny and the Juniors. And since we read so often 'don't tell me what to do', don't ask for help if you don't take our view with any merit. The Ignore button get's to be space bar size, even though it itches sometimes ;>)
WCG
Please help to make the Forums an enjoyable experience for All! |
||
|
|
JmBoullier
Former Community Advisor Normandy - France Joined: Jan 26, 2007 Post Count: 3716 Status: Offline Project Badges: 
|
If someone asks "how to cache more work", an answer like "your ver-x.y.z is unsupported, you'll need to change to v6.2.28 before I'm answering the exact same question" doesn't make any sence to me. Not much more or less than your repeated "don't use 6.2.28, it's obsolete, install the latest version from Berkeley." By the way, maybe sometime you will tell us why you are trying to discourage WCG forum users from using the version that they know we will do everything we can to support if they have a problem with it? I could understand that you do that in the fora of other grids, but here it does not make sense, as you say, nobody asks you to support a version that you do not like. Thanks in advance for explaining. Jean. |
||
|
|
mikey
Veteran Cruncher Joined: May 10, 2009 Post Count: 826 Status: Offline Project Badges:
|
I completely disagree. If you want HELP, it is your best interest to use supported software. If you are not going to bother the WCG staff and CAs, feel free to do as you like. A quick look on Project Credit Comparison shows of WCG's currently... 198034 active computers, so is 18222 of these also actively running SETI@home, meaning 9.2%. According to SETI@home's List of recently connected client types roughly 0.1% of connections is from v6.2.28. This means 9.0% of WCG-computers runs SETI@home and also don't run v6.2.28. How many is active in other projects and not SETI@home is more difficult to know, but would guess atleast 10% of active WCG-computers runs multi-project and non-v6.2.28. For multi-project, v6.2.28 is often not an option, either due to lacking CUDA-support, or due to being 32-bit-only. (According to connection-statistics, roughly 30% of connections from SETI@home-windows-clients is from 64-bit BOINC-clients) How many computers that is only active in WCG also don't run v6.2.28 is unknown, someone from WCG can answer this if they wants... But regardless of if only the 10% multi-project-computers runs other BOINC-clients, it's still my opinion that it's in WCG's best interest to also try supporting these. If someone asks "how to cache more work", an answer like "your ver-x.y.z is unsupported, you'll need to change to v6.2.28 before I'm answering the exact same question" doesn't make any sence to me. I agree with this point of view, it is better to try and help a user, if you can, than try and tell them to switch versions since that version isn't the recommended one. Boinc is still Boinc, yes the newer versions do things that the original Boinc never dreamed of doing but so are the users! I mean WCG does not do gpu processing right now, but Boinc users do! Does that mean that anytime a Boinc user that uses Boinc to crunch for MilkyWay or Seti or whatever and therefore must use a higher version of Boinc than the version currently supported by WCG that the WCG Helper folks should tell the user 'go away we can't help you?'! Yea that will encourage more people to come and crunch for WCG! As Helpers it is sometimes necessary to help people who do things in non standard and even non approved ways. Now that being said it is NOT always possible to help every single person just because they ask for it. Some of those people that do things in non standard ways have problems that can be solved by the current Helper folks, some questions are just simple ones! If a question is beyond the Helper person that is why Forums exist, so the rest of the community can help and learn too. Just my perspective and opinion!   |
||
|
|
Ingleside
Veteran Cruncher Norway Joined: Nov 19, 2005 Post Count: 974 Status: Offline Project Badges:
|
If someone asks "how to cache more work", an answer like "your ver-x.y.z is unsupported, you'll need to change to v6.2.28 before I'm answering the exact same question" doesn't make any sence to me. Not much more or less than your repeated "don't use 6.2.28, it's obsolete, install the latest version from Berkeley." AFAIK the only times I've told anyone to upgrade from their current client (regardless of v6.2.28 or any other client) is if they've asked about "how to auto-suspend then runs a particular program" since they needs v6.3.13 or later for this functionality, in the multi-OS-setup-case, and atleast once to Sekerob then he ran an outdated alpha-build. There was also once or twise something along the lines of, "I don't know if you've hit a bug or not in v6.2.28 since I can't test myself, but if you has hit a bug, either change client or work-around the bug". By the way, maybe sometime you will tell us why you are trying to discourage WCG forum users from using the version that they know we will do everything we can to support if they have a problem with it? I could understand that you do that in the fora of other grids, but here it does not make sense, as you say, nobody asks you to support a version that you do not like. Thanks in advance for explaining. Jean. Well, my quote on top of this message should sum up my point fairly nicely, but if you wants a little different wording, it would be something along the lines of: "If you're currently running v5.10.45, v6.2.xx or v6.6.xx and don't have major problems, there aren't really any good reasons to change client at this point, except if you wants to use a feature missing in your current client." Or, said a little differently, "In majority of instances, problems is BOINC-client-independent, so changing BOINC-client is often a waste of time". "I make so many mistakes. But then just think of all the mistakes I don't make, although I might." |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
Ingleside, very off topic, but many times you write then, where in context the proper is when. Looses less in translation, particular for those not of native English tongue :D
----------------------------------------On version use, heck, why is it that after escapades on one or the other 'advanced alpha/beta' or yet another Berkeley 'recommended' release I keep returning to 6.2.28 or 5.10.45. Is that not telling? As mentioned I had 5 live installs on my test box, now 6 including a fork. Latest comment I saw at Berkeley "don't expect the next client to behave the same as the previous". But is that not how to create stability and comfort so most volunteers can run set and forget?
WCG
Please help to make the Forums an enjoyable experience for All! |
||
|
|
Ingleside
Veteran Cruncher Norway Joined: Nov 19, 2005 Post Count: 974 Status: Offline Project Badges:
|
Ingleside, very off topic, but many times you write then, where in context the proper is when. Looses less in translation, particular for those not of native English tongue :D You're not the first w/t-hat's commented on w/t-his, but being non-english it's unlikely will ever learn the correct usage.  On version use, heck, why is it that after escapades on one or the other 'advanced alpha/beta' or yet another Berkeley 'recommended' release I keep returning to 6.2.28 or 5.10.45. Is that not telling? As mentioned I had 5 live installs on my test box, now 6 including a fork. Latest comment I saw at Berkeley "don't expect the next client to behave the same as the previous". But is that not how to create stability and comfort so most volunteers can run set and forget? While haven't tried single-project, by suspending all projects except one, haven't detected any big differences between v5.10.45 and v6.6.xx, so appart for changes to BOINC Manager wouldn't expect most single-project-users to find any big differences either. For multi-project there are some changes, atleast in how low resource-share-projects is handled as far as "high priority" and work-request is concerned. Not sure how it is with equal resource-share-projects... To get a better feel of how v6.6.xx really works, should preferably let the client run with the same settings for a month. Even better would be if was possible to compare with an exactly similar computer running v5.10.45 or v6.2.xx parallell with v6.6.xx... BOINC can normally run unattended on it's own, and appart for then users decides to upgrade, there's not normally anything to do. For the users that monitors their BOINC-client 24/7 (ok, they'll likely sleep a little so let's say 20/7), the client has never followed the resource-share short-term. Some users then sees this will start micro-managing, by suspending projects and tasks and so on, and to these users BOINC never works "as it should", and v6.6.xx isn't any different in this regard. "I make so many mistakes. But then just think of all the mistakes I don't make, although I might." [Edit 1 times, last edit by Ingleside at Aug 4, 2009 4:53:45 PM] |
||
|
|
|