|
41)
Message boards :
Number crunching :
Process got signal 11
(Message 215)
Posted 21 Sep 2011 by Dagorath Post: Works on Fedora 14 and Ubuntu 10.10. |
|
42)
Message boards :
Number crunching :
Massive drop of credits per CPU hour
(Message 213)
Posted 20 Sep 2011 by Dagorath Post: What huge foulup? And what are fraggles? |
|
43)
Message boards :
Number crunching :
Massive drop of credits per CPU hour
(Message 211)
Posted 20 Sep 2011 by Dagorath Post: Unfortunately I have not gotten any work units that run for 36 minutes and pay me 50 points, which is a pity. And you won't see one. I cheated the credit system on that task to see if it can be done. It can be done but I didn't get the credit I thought I would get. Notice the elapsed time for that task was 10,000,000 (not real, I cheated that number) but I received only 50 credits. When I tried cheating at Test4Theory@home I received HUGE credits for 10,000,000 secs elapsed time, 74,000 IIRC. Don't worry, I 'm not cheating on a regular basis, just testing. I've done 1 task here and 2 at T4T and that's all I will do. The cheat method is far too much work to do regularly and I really don't care about having a big RAC anyway. I have not and will not share the cheat with anybody except curious project admins. Another reason I cheated was to see if CreditNew normalizes the way it's supposed to. Here at NumberFields it does but does not seem to at T4T. As I said, I expected HUGE credits for 10,000,000 secs elapsed time but received only 50. That's because CreditNew attempts to keep an "average" for you. If you turn in a task that is very high compared to your average it bumps the number down. If you turn one in that is very low it bumps the number up. It's to reduce cheating. That's why you see "randomness" in NumberField credit awards. At T4T the tasks all run 24 hours so I think the normalizing algorithm there wouldn't be as effective and would kick in only after a volunteer had cheated many tasks. What I am showing is the fact that the credit is all over the place and on average for me it is very low. I think I explained that above but I'll add that it seems to me the bigger the spread in elapsed times the more random the credit awards appear to be but it's just becausae of the normalizing function. At T4T the elapsed times are nearly exactly 24 hours (fast CPU, slow CPU makes no difference) all the time and credit awards don't vary much after you've done a few tasks. Slower CPUs tend to get lower credits per task because the benchmarks are used in the credit calc algorithm. If you compare credits from projects using CreditNew to credits from projects not using CreditNew you'll always see higher credits/hour from those not using CreditNew. It's Dave A's way of leveling the playing field for projects and you can blame it on irresponsible, unscrupulous projects like Milkyway and others who paid ridiculously high credits just to attract more volunteers. It's too bad rogue projects like that can't be culled from the community but that's another story. Now the good news! According to project admins I've heard from, Dave A has folded the CreditNew code into recent server code in such a way that makes it quite difficult to substitute one's own credit code. And further server code updates after substituting custom credit code become difficult. Expect more and more projects to start using CreditNew as they update their server code. The days of whoring for credits are nearly at an end. We are CreditNew. You will be assimilated. |
|
44)
Message boards :
Number crunching :
Massive drop of credits per CPU hour
(Message 207)
Posted 18 Sep 2011 by Dagorath Post: I can't see what you guys are complaining about. Take a look at this task. From the Time Sent and the Time Reported one can see it was on my computer for 36 minutes but I received 50 credits for it. Seems generous enough to me. |
|
45)
Message boards :
Number crunching :
Error in the PARI system
(Message 185)
Posted 12 Sep 2011 by Dagorath Post: I've reset NumberFields and lowered BOINC's disk space allottment to 20 GB. Ill let you know if I get more -177 errors. |
|
46)
Message boards :
Number crunching :
Error in the PARI system
(Message 183)
Posted 11 Sep 2011 by Dagorath Post: Hmmm. It looks like 40 GB isn't enough. I just had 3 tasks all crash at the same time with exit code -177 on my i7. They are task number 59501, 58172 and 58115. There were 7 NumberFields tasks running concurrently. Those 3 crashed at exactly the same time, the other 4 are still running.. Why not the other 4 too? Why not all 8 tasks? The max disk space was exceeded so why not all 8 tasks? What differentiates those 3 from the others? I'm beginning to think it's not the limit in BOINC preferences that's being exceeded. I think it's the rsc_disk_bound that's exceeded. But that wouldn't give an exit code -177, unless the exit code lookup table is screwed up or the code that does the lookup is wonky? OK, I've boosted the limit in BOINC prefs to 50 GB. We'll see what happens. |
|
47)
Message boards :
Number crunching :
Error in the PARI system
(Message 182)
Posted 11 Sep 2011 by Dagorath Post: I had 20 GB allotted on both of my hosts before I joined NumberFields because I run a project (Test4Theory@home) on both of them that needs 10 GB. When I noticed the disk space errors a couple days ago I bumped it up to 30 GB. That seems to have fixed my 2 core computer but I just now checked the i7 (8 cores with HT) and it's still overrunning the disk space, probably because it runs up to 7 NumberFields tasks concurrently. I've bumped that one up to 40GB now and will continue to monitor it. I wonder how BOINC determines which project exceeds the limit? None of my other projects get that error. How does it know NumberFields is to blame and not Test4Theory, for example? All projects draw from the 1 well. It's not like they each have their individual allotment. |
|
48)
Message boards :
Number crunching :
Error in the PARI system
(Message 179)
Posted 10 Sep 2011 by Dagorath Post: I'm getting PARI errors too. http://stat.la.asu.edu/NumberFields/result.php?resultid=59267 *** overflow in t_INT-->t_INT assignment. *** Error in the PARI system. End of program. http://stat.la.asu.edu/NumberFields/result.php?resultid=59281 *** bug in PARI/GP (Segmentation Fault), please report *** Error in the PARI system. End of program. If you browse through my errored tasks you'll also see I've been getting "Maximum disk size exceeded", exit code -177, but I haven't seen anymore of those since alloting more disk space to BOINC so ignore them. |
|
49)
Message boards :
Number crunching :
Massive drop of credits per CPU hour
(Message 168)
Posted 6 Sep 2011 by Dagorath Post: I am not familiar with the server code so all I can offer is what I've heard. The admin at AQUA@home recently said that the CreditNew scheme is kind of intertwined into the server code in a way that makes it difficult to monkey with or opt out of. (With earlier server versions you could apparently easily substitute your own credit granting code for the built-in credit code). He also said that monkeying with CreditNew would make it difficult to upgrade to subsequent server code. Maybe he was right, maybe he was just lazy, maybe he just wasn't imaginative enough, we'll never know for sure. They've shutdown that project, btw, nothing to do with credits. Don't be discouraged by what I have said about AQUA admin's "experience". Monkey away with it as you will. You might want to consult with David Anderson first, not to obtain permission because you don't need it, but to get an idea of the pitfalls. Don't be afraid of a credit war either, we're all used to it and most just don't care anymore. The problem with credits has been with us for so long many crunchers just ignore it. If you don't do something to boost your credit payout you will definitely have some crunchers leave. Exactly how many remains to be seen. My advice is let the credit whores go. You'll retain a solid base of crunchers dedicated to the work you do. It's up to you. |
|
50)
Message boards :
Number crunching :
Comp errors on 1.05 for Gentoo Linux
(Message 150)
Posted 6 Sep 2011 by Dagorath Post: I'll bite. Followed your directions and got: Reading symbols from /home/kim/BOINC/projects/stat.la.asu.edu_NumberFields/GetBoundedDecics_1.06_x86_64-pc-linux-gnu...done. It took about 1 sec to get from "Starting program" to "Program exited with code 01". Does that sound right? I cd'd to the NumberFields dir in BOINC/projects before running gdb. It's now paused at the gdb prompt. I'll let it sit there until I hear back from you. BTW, I'm on Ubuntu 10.10 not Gentoo. |
|
51)
Message boards :
Number crunching :
one wu at a time
(Message 110)
Posted 3 Sep 2011 by Dagorath Post: You're welcome, Eric. BTW, BOINC 6.12.34 is now the stable recommended version for Linux and Windows, 6.12.35 for Mac. And I blew the URL for the Berkeley installer in my last post. Try The Berkeley Installer. |
|
52)
Message boards :
Number crunching :
Massive drop of credits per CPU hour
(Message 109)
Posted 3 Sep 2011 by Dagorath Post: If you're on the current server_stable code and haven't customized the parts of the code that calculate/award credits then I am pretty sure you're using CreditNew. I don't really follow the server versions as much as I do the client versions so I could be wrong. I crunch for the science and don't give 2 hoots for the credits but you'll find a lot of crunchers hate CreditNew with a passion because it doesn't yield the credits per hour they expect to receive. |
|
53)
Message boards :
Number crunching :
Process got signal 11
(Message 102)
Posted 2 Sep 2011 by Dagorath Post: I'm no linux expert but shouldn't this be dynamic? Don't know, maybe I'm mixing this up with libraries. I agree. If your app was being installed by a package manager then any missing shared libs would be installed as needed but it's not being installed via package manager. Leave it static, please. It's not using a lot of memory so its not a problem. |
|
54)
Message boards :
Number crunching :
Longer deadline possible?
(Message 101)
Posted 2 Sep 2011 by Dagorath Post: Thanks Eric. Nah, you get more work than you can complete on time because your cache is too big. If you have a reliable 24/7 connection then there is no reason to set "Connect about every..." to more than 0 and "Additional cache..." to more than 0.1. The 'short' deadlines and long predicted runtimes force the project into panic mode and stop any other projects from running, which is why I only let one at a time run to give the other core a chance to do something else. Keep a small cache and don't worry about panic mode. They may go into panic mode for a while but eventually that stops and then your other projects get their time too. The more you micro-manage it the worse you make the problem. If you like baby sitting and aborting and suspending then keep a large cache and fill your boots with the baby sitting. If you want to make it easy on yourself then keep a small cache and let BOINC do its thing. Been doing that for years and it works just fine. |
|
55)
Message boards :
Number crunching :
one wu at a time
(Message 100)
Posted 2 Sep 2011 by Dagorath Post: @ Nate, How did you install BOINC? Did you install from Ubuntu repositories using apt-get or did you use the Berkeley installer from the BOINC site? If you used the Berkeley installer then you can upgrade to BOINC 6.12.34. I did and it works fine. You might run into trouble with a few missing shared libs but if you install those you'll be OK. It worked for me. Try it on 1 host and if it works there you can do it on your other hosts too. Then you can use the <fetch_minimal_work>1</fetch_minimal_work> option in cc_config.xml which will restrict you to receiving only 1 task per core. I'll help you upgrade to 6.12.34 if you run into any trouble. If you installed BOINC from Ubuntu repositories then you can still upgrade BOINC to 6.12.34 by downloading the Berkeley installer, installing into a temporary directory and copying ~/temp/boinc to /usr/bin/boinc_client. First rename your current /usr/bin/boinc_client to boinc_client_6.10.58 in case you want to switch back. You may have to install a few shared libs but it works. You can leave BOINC manager at 6.10.58 and it will work fine with a 6.12.34 client. I know because that's what I do on my Ubuntu machine. Directions for using the Berkeley installer are [http://boinc.berkeley.edu/wiki/Installing_BOINC#The_Berkeley_Installer]here[/url]. Also, you're asking for trouble running a project that has 50 hour tasks that don't checkpoint. I refuse to run such projects . They can bloody well make their app checkpoint if they're going to have tasks run that long. However if you really want to run their tasks then go into your BOINC preferences and set your task switch time to 50 hours or however long those tasks require. Then BOINC should run them start to finish with no interruption. If you don't want to do that then set your preferences to leave apps in memory when suspended. That way they restart where they leave off even if they don't checkpoint. I wouldn't hold my breath waiting for this project to add the option to download however many tasks you want. I am confident you can cope with your problems using settings already available to you. Don't be afraid to ask questions, we're here to help. |
|
56)
Message boards :
Number crunching :
Massive drop of credits per CPU hour
(Message 99)
Posted 2 Sep 2011 by Dagorath Post: If this project uses the CreditNew scheme for calculating credits then you can expect to see a drop in credits after completing a few tasks. After that the credits should level out and not change much. |
|
57)
Message boards :
News :
Thank you to all the new participants.
(Message 98)
Posted 2 Sep 2011 by Dagorath Post: I was surprised to come home from vacation and see so many new participants. I only told a handful of people, but apparently the word got around. But this is good! You ain't seen nothin' yet. I've been crunching for the ABC@home project, another math oriented BOINC project, for a few years. They're just about finished their search so I've posted a message in their forum to invite volunteers to join this project. Also there is a new message on the BOINC dev forums mentioning this project. Are you prepared for the onslaught of our mighty mighty BOINC "supercomputer"? We've left many an unprepared project bleeding in the ditch, disks exploded, data bases fried, too many connections, tires flat, coconuts blown clean off the palm tree. Test4Theory@home was our most recent "victim". They had 6000 new volunteers join in the space of about 3 days after a few articles about their project appeared in some online magazines, blogs, etc. The poor buggers didn't know what hit them. Took them 2 weeks to recover. Do you want more advertising or do you want the volunteer numbers to ramp up slow and easy? I doubt you'll get 6000 new crunchers in 3 days but... who knows for sure. |