| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
| World Community Grid Forums
|
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 49
|
|
| Author |
|
|
mirabilos
Cruncher Joined: Mar 25, 2008 Post Count: 37 Status: Offline Project Badges:
|
Yeah… maybe your techs have an idea, as I asked in the BOINC IRC channel already
----------------------------------------and got rather clueless replies. I’ve had WUs not finishing not only from WCG but also from e.g. Spinhenge and Sztaki DG. Other WUs from these (and other) projects finish fine, and some finish after running three times. I wonder if there is a way to tell the core client if a WU has finished manually. I tried editing client_state.xml, but that skips uploading the results and leads to problems. As for the WCG applications: I’m trying faah now, but lr657_ 00018_ 3-- (hpf2) finished with valid state, so _in general_ it should be usable. I did not get any Beta units, but I’ll try the other projects as well when I’m done with the faah WU, and report here. Plus point of WCG: you’re linking the (non-graphic) apps statically, which is great. Other projects don’t, and it’s often a hassle to get to the libraries needed. (I managed to get the HPF2 graphics running, though slow due to use of Mesa.) |
||
|
|
mirabilos
Cruncher Joined: Mar 25, 2008 Post Count: 37 Status: Offline Project Badges:
|
Okay, faah is done, 3 times the CPU time of the other person, and in Inconclusive
----------------------------------------state, which almost certainly means the result is bad. And I did see a Signal 4 at some time point… maybe it tried to use SSE? My Athlon XP doesn’t have SSE yet. Next on the list is hcc1. I'll keep you informed. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
The work units have to give the same result on almost any processor. This means compiling with almost no optimisation.
In short, your problems are caused by the OS, not the CPU. Perhaps the signal 4 is coming from your Linux emulation layer? |
||
|
|
mirabilos
Cruncher Joined: Mar 25, 2008 Post Count: 37 Status: Offline Project Badges:
|
I thought about that, but the source code does not send this signal,
----------------------------------------and just passes it through (it has a number mapping table, but SIGILL is 4 for both Linux and BSD, so it's an 1:1 mapping here). As it's a statically linked executable, it won't be the shlibs either… I have no idea where that SIGILL comes from. I wonder if attaching a debugger (how? and how to get the application version with debugging symbols) would work… in theory, linux ptrace() is emulated, so a Linux gdb might work. This is only if someone really has interest in tracking it down… I just notice the fact and will un-tick the faah project in my list for now. |
||
|
|
mirabilos
Cruncher Joined: Mar 25, 2008 Post Count: 37 Status: Offline Project Badges:
|
Now this is interesting. The result in question, faah4035_ apv_ xmd06300_ 03_ 0--,
----------------------------------------has FOUR in state Inconclusive(!) and one In Progress… weird. In the meanwhile, hcc1 X0000045951336200501190754_ 1-- returned after 27.35 CPU hours and is Inconclusive too (the other one has 8.95 CPU hours, but I suppose it’s just my old Athlon XP which is so slow). Let’s see what will become out of these. I’m crunching a dddt right now, after down- loading a new version of the application. |
||
|
|
mirabilos
Cruncher Joined: Mar 25, 2008 Post Count: 37 Status: Offline Project Badges:
|
Okay, here it stands:
----------------------------------------• 1 faah: Invalid • 1 hcc1: Invalid • 2 dddt: Invalid Now ac@h is missing (don’t get a WU for it right now), and hpf2 still crunching, the last hpf2 was Valid. |
||
|
|
mirabilos
Cruncher Joined: Mar 25, 2008 Post Count: 37 Status: Offline Project Badges:
|
Ok, got a few HPF2 erroring out and two invalid (but recently, I had heat issues on
----------------------------------------my (primary) laptop), and the first Rice unit Valid ☺ No ac@h yet though. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Hello mirabilos,
If you look at the statistics for ACAH ( http://www.worldcommunitygrid.org/stat/viewProject.do?projectShortName=acah ) you will see that there were only 10 results yesterday. This project is coming to a halt while the grad students write their dissertations on the results. There will probably be a long break before a new group of young researchers start putting out new work units. Lawrence |
||
|
|
zuriel
Cruncher Joined: Feb 20, 2007 Post Count: 3 Status: Offline |
kinda same problem here, i installed boinc here at work to at least make my computer do something useful while programming. it's not even too slow - amd 64x2 3800 2gig of ram - but the work units are way too big. i only come around a few times a month and always for less than 6 hours. This effectively prevents me from completing any work units in time so atm running boinc at work is totally pointless and in fact more of a waste of power.
Why the heck can't the work units be smaller?? I imagine a lot less power would be wasted by boinc users all over the world if wu unit would go down considerably, and i see no good reason not to do that. So please ne1 explain this to me it drives me nuts ![]() |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
I'm not sure I follow, zuriel. Are you saying you only use this computer for a few hours a month? If so, then it really isn't practical to run BOINC. Don't let your good intentions get in the way of practicality.
|
||
|
|
|