21) Message boards : Closed Issues : Validator broken or slow? Deprecated: Creation of dynamic property BoincUser::$prefs is deprecated in /var/boincadm/prj/html/inc/forum_db.inc on line 164 (Message 3593) Posted 14 Sep 2019 by Michael Goetz Post: It seems that no tasks have been validated for almost a day. My most recent validated task was received at the server at 13 Sep 2019, 15:51:43 UTC, and 8 tasks since then are pending validation. The server status page shows 2781 tasks waiting for validation.

22) Message boards : Number crunching : variation in credit allocation (Message 3588) Posted 9 Sep 2019 by Michael Goetz Post: As a follow up, I thought I'd post the following. I didn't set the original credit at PrimeGrid, but Jim and I have been running PrimeGrid for about 7 years now and we've tried to keep the credit internally consistent. When AVX CPUs first came out, I realized the BOINC credit system couldn't be used at PrimeGrid anymore. Using the stock credit system, people buying new CPUs with AVX would get half the credit that people with older CPUs receive. That would attract people with slow computers to PrimeGrid and drive away people with the fastest computers, which is exactly the opposite of what we wanted! So we built a better system, where we could model the expected computation time of every task, and assign credit based on that model. It's not perfect, but it's pretty good -- and it's good enough to keep the users from complaining about it. It wasn't easy to do, and it's only feasible if your tasks are predictable. Not every project can do credit that way. But I never compared the credit we give out to the "reference standard Cobblestone", like I did just now for your tasks. I thought that might be an interesting exercise. I have 9 computers running our new PPS-DIV application. I picked a representative task for each computer, and compared the actual credit (generated by our modeling system) against the the theoretical credit based on the Cobblestone formula. This is what I got for the actual vs. theoretical credit, based on the run times for the task and the characteristics (GHz and CPU family) for the 9 computers: Anything above 100% means I got more credit than the Cobblestone formula suggests, under 100% means I got less than the formula predicts. 132% 116% 137% -- this is the computer I'm using here 125% 92% 106% 87% 102% 80% Even at PrimeGrid, with a credit system as highly tuned to our actual applications as I know how to make it, the credit is still varying between 80% and 137% of the theoretical correct amount. It varies according to which computer is running the tasks. Even the last 5 computers on that list, which are all identical Xeon(R) Gold 6140 CPUs, vary from 80% to 106%. It's unrealistic to expect any project to do better than that. If all the tasks I ran here had received 79-ish credits, it would have come out to very close to the ideal 100%. At that credit rate, I think you're as close to perfect as you can get. Yes, it will be less credit than at PrimeGrid, but that's because our apps can make use of the SIMD instructions to do multiple computations in parallel. That produces more credit -- and also more heat, uses more electricity, and requires better cooling solutions. For a "normal" app, I think at the higher credit rate you've got it set correctly. The results are always going to vary from computer to computer, so there's no "perfect" answer.

23) Message boards : News : Badges (Message 3586) Posted 9 Sep 2019 by Michael Goetz Post: The badge signature site https://signature.statseb.fr has also picked up your badges! :) Edit: As you can see in Steve Dodd's signature image three posts before this one.

24) Message boards : Number crunching : variation in credit allocation (Message 3585) Posted 9 Sep 2019 by Michael Goetz Post: Ok, I'm new here, but I'm more than a little familiar with how BOINC credit works (or doesn't). Data point: I'm running on just the full cores (no hyperthreading) on a 1st gen Core i3. It's actually a little faster, but let's call it a 2 GHz CPU. According to WUProp, I have about 48 core-hours done on this CPU. Let's call that 2 days. On a modern CPU, it's not unreasonable for a typical application to get 1 FLOP per clock cycle. The definition of BOINC credit ("cobblestones") is: "1/200 day of CPU time on a reference computer that does 1,000 MFLOPS based on the Whetstone benchmark" (See https://boinc.berkeley.edu/wiki/Computation_credit) A 1-GFLOP computer should earn 200 credits per day. This 2-GFLOP computer, running for two days, should have earned 4*200=800 credits. In fact, It earned. 546 credits. That's about 32% lower than the BOINC standard. If you recently increased the credits, then they were substantially below standard before the increase. All of these tasks were run on September 8th and 9th. Even though the run times for the all the tasks were similar, most of the tasks were 38 credits and two were 79 credits. If all of the tasks were 79 credits, it would total 869, which is pretty close to the correct value. (800 is a nice round number, but the computer's actually a bit faster, so 869 is pretty close to correct.) If all the tasks were 38 credits, it would total 418 -- about half of what it should be. For what it's worth, some projects (like PrimeGrid) give out more credit because their apps are highly optimized and compute more than 1 FLOP per clock cycle. With the right CPUs, some of our apps can execute up to 16 FLOPS per clock cycle by using AVX-512 and FMA3 instructions. So, of course, the credit per hour is correspondingly higher. But for a normal app, it's fair to assume one FLOP per clock cycle. Setting credit fairly in a BOINC project is a tough, almost impossible, and definitely thankless task. Hopefully you'll find the data provided above to be helpful

25) Message boards : Number crunching : Information about project participants (Message 3164) Posted 26 Feb 2019 by Michael Goetz Post: no. I need location in config file where to enable it. It's not a config file. The menu is *probably* in html/inc/bootstrap.inc in a function called sample_navbar(), unless you renamed it to something else. That's the function that defines each menu item.

Previous 20

©2024 Tomáš Brada