Message boards :
Number crunching :
Massive drop of credits per CPU hour
Message board moderation
Previous · 1 · 2 · 3 · 4 · Next
Author | Message |
---|---|
Send message Joined: 8 Jul 11 Posts: 46 Credit: 7,144,042 RAC: 0 |
Well I can't work out why my faster computer (by only 200 MHz, an AMD Phenom II 1100T @ 3.3 GHz, my other is AMD Phenom II 955 @ 3.2 GHz), is getting consistently much lower results than my slower machine. I really don't understand how the credit system works but I gather is is all based on these benchmarks that run initially. Perhaps there was something else running during the benchmark phase which is lowering the scores on your Phenom. I believe you can force the manager to re-run them. Can you give that a try before you bail on your AMD? |
Send message Joined: 2 Sep 11 Posts: 57 Credit: 1,274,345 RAC: 0 |
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. BOINC FAQ Service Official BOINC wiki Installing BOINC on Linux |
Send message Joined: 3 Sep 11 Posts: 30 Credit: 10,537,849 RAC: 16,232 |
Unfortunately I have not gotten any work units that run for 36 minutes and pay me 50 points, which is a pity. What I am showing is the fact that the credit is all over the place and on average for me it is very low. Some run time and credit awarded examples:- Runtime(sec) Credit Cr/h 54,818.78 208.09 13.67 50,413.69 174.31 12.45 50,402.27 296.11 21.15 47,959.63 132.41 9.94 18,036.39 62.99 12.57 13,113.98 45.41 12.47 11,804.94 26.74 8.15 10,181.86 19.70 6.97 3,661.20 20.80 20.45 1,665.88 5.12 11.06 As you can see credit just seems random. Redoing benchmarks would make very little difference, the machines are mainly Boinc crunching units and do very little else. Benchmarks have been consistently low for Linux since I first started Boinc many years ago, and nothing much has changed (unless I upgrade to 64 Bit where the benchmarks seem a lot better). Since my last post (6 days) my score has only moved from 4,500 to 4,800, so as I said I am crawling to the 5,000 point mark. Conan (Edit :-- Just past the 5,000 point mark due to a large WU) (Just checking work units and I found a new Low 4.5 cr/h for this WU after over 14 hours of processing for 66.98 points) |
Send message Joined: 8 Jul 11 Posts: 1344 Credit: 529,318,942 RAC: 565,795 |
I am in the process of porting the app to 64bit windows. I am hoping this might fix the problem. If not, I will need to look under the boinc hood to see what is going on. |
Send message Joined: 2 Sep 11 Posts: 57 Credit: 1,274,345 RAC: 0 |
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. BOINC FAQ Service Official BOINC wiki Installing BOINC on Linux |
Send message Joined: 19 Aug 11 Posts: 76 Credit: 2,002,860 RAC: 0 |
Unfortunately I have not gotten any work units that run for 36 minutes and pay me 50 points, which is a pity. BRIGHT IDEA! now we know who (and maybe some other fraggles) is responsible for that huge foulup. thank you very much. :( |
Send message Joined: 2 Sep 11 Posts: 57 Credit: 1,274,345 RAC: 0 |
What huge foulup? And what are fraggles? BOINC FAQ Service Official BOINC wiki Installing BOINC on Linux |
Send message Joined: 7 Oct 11 Posts: 17 Credit: 17,470,176 RAC: 3,103 |
Well I can't work out why my faster computer (by only 200 MHz, an AMD Phenom II 1100T @ 3.3 GHz, my other is AMD Phenom II 955 @ 3.2 GHz), is getting consistently much lower results than my slower machine. I am sure that almost any other Boinc Project Admin will help you if they can, you might try Collatz although it is mostly a gpu project but some people use their cpu too. He gives more than the average credits per workunit and seems to be almost one guy handling everything. He is very responsive to the message boards. |
Send message Joined: 8 Oct 11 Posts: 1 Credit: 25,100 RAC: 0 |
11 1/2 hours for 211 credits...so long |
Send message Joined: 29 Aug 11 Posts: 4 Credit: 2,904,753 RAC: 0 |
|
Send message Joined: 8 Jul 11 Posts: 1344 Credit: 529,318,942 RAC: 565,795 |
Any news? I believe this is related to the other issue we have been having: http://stat.la.asu.edu/NumberFields/forum_thread.php?id=35 The really short work units are skewing some computations and these apparently have an effect on the credits. I've noticed in general that the faster wus get more credits per hour than the slower ones. Hopefully we'll have this fixed in the next couple days, but it may take a little longer for the credit calculations to stabilize. Thanks for your support! |
Send message Joined: 29 Aug 11 Posts: 4 Credit: 2,904,753 RAC: 0 |
Ah ok. Have you make some other changes? At the beginning of the project Win & Linux-Host get nearly the same credits (Linux a little bit more; in an earlier post you explain that the Linux is nearly 2 times faster). But now it looks like that Winhost get more credits (i look at this the last days). In the last days i get 20-22k credits daily (4 hosts x 24h, i7 uses only 5-6 threads for NumberFields, the other 3 hosts crunch only NumberFields) but a Q6600 with Win is enough to get more credits (or look at your Winhost, ypu nearly double my credits in the last day). |
Send message Joined: 8 Jul 11 Posts: 1344 Credit: 529,318,942 RAC: 565,795 |
Ah ok. A few weeks ago I did find a way to make the windows app faster by turning on a global optimization flag. It's now almost as fast as the linux version. Credits are awarded based on cpu time and how fast the server thinks the host is. If a host received a bunch of fast wus, it's very possible that the stats got skewed and the server thinks it's faster than it really is, resulting in higher credits for that host. |
Send message Joined: 21 Sep 11 Posts: 3 Credit: 17,155,801 RAC: 0 |
I feel I'm earning too much credit, don't you? Not so far may be. |
Send message Joined: 8 Jul 11 Posts: 1344 Credit: 529,318,942 RAC: 565,795 |
I feel I'm earning too much credit, don't you? Doesn't look like you're getting more than the average user. All users are getting more credits than the typical project due to that issue we had a couple weeks ago. I was hoping the statistics would stabilize a little quicker. I could always do an "app_reset" to reset the stats, but I'm a little hesitant to do that now that everything else is running smoothly. |
Send message Joined: 23 Aug 11 Posts: 1 Credit: 1,167,514 RAC: 0 |
I feel I'm earning too much credit, don't you? You can always stop crunching... |
Send message Joined: 7 Nov 11 Posts: 2 Credit: 3,474,436 RAC: 0 |
I hope our credits are safe... |
Send message Joined: 2 Sep 11 Posts: 57 Credit: 1,274,345 RAC: 0 |
They are not safe. I steal some every day. BOINC FAQ Service Official BOINC wiki Installing BOINC on Linux |
Send message Joined: 8 Jul 11 Posts: 1344 Credit: 529,318,942 RAC: 565,795 |
I hope our credits are safe... I didn't know what you meant at first, but then someone told me what happened at AQUA, where they were forced to take credits away from people. For most users I believe the credits are in a reasonable range (<100 per hour), although they seem to be higher than the typical project. As a precaution, I went ahead and ran the "app_reset.php" script. It ran successfuly, so we will just have to wait and see what happens. It should reset all the corrupted stats and the credits should go back to normal (whatever that is). For those who are interested, here is an old thread relating to the problem that AQUA had (Thanks for the link Frank): http://www.setiusa.us/showthread.php?1803-AQUA-User-Host-and-Team-credit-were-rolled-back Eric |
Send message Joined: 28 Oct 11 Posts: 180 Credit: 252,206,993 RAC: 180,679 |
I've been monitoring the credit rate on my four hosts since I joined the project three weeks ago. (Direct link) All four hosts have similar speeds (~2.4 to 2.5 GHz), though you would expect the i5, being dual core with HT active, would have a lower real-world performance than the other three, which are all true quad-cores. All of them have settled down now, though in every case it's taken several hundred, even thousand, tasks to reach that point. What is very apparent from the graphs is how sensitive the credit mechanism is to the runtime of the very first few tasks which pass through the system. Since all tasks have the same estimated (<rsc_fpops_est>) runtime, a succession of long-running tasks in the early days makes the BOINC server think the host is slow (yellow curve) and worthy of little credit: a lot of short tasks makes BOINC think the host is fast (dark blue curve) and it gets a lot of credit. [I hope I've got the signs right in that analysis!] I've attempted to start a discussion on the BOINC development mailing list about how well suited the current server code is to projects which can't consistently predict runtime in advance (in my opinion: not very), but it seems to have died out. There does seem to be a particular problem, which could easily be sorted out if the developers were prepared to retreat by one step in CreditNew: if you have recently run a long, slow task (resulting in a high local DCF), you may well be allocated more work than you want or need the next time you fetch new tasks. This is especially noticable with the experimental v6.13.xx line of BOINC clients, which tend to fetch work less often but in larger volumes. |