Message boards :
Number crunching :
Credit Calculations.
Message board moderation
Previous · 1 . . . 5 · 6 · 7 · 8 · 9 · Next
Author | Message |
---|---|
Send message Joined: 29 Aug 07 Posts: 486 Credit: 576,548,171 RAC: 0 |
Don't forget it's the projects that are getting something for nothing - a lot of CPU time. (The costs of running the servers, etc, is less than buying that much CPU power) It's the never ending argument isn't it, with both sides having very reasonable arguments for their side. As far as the Projects getting something for nothing goes all I can say nobody's holding a gun to my head or yours telling me or you if you don't run the BOINC Projects they'll pull the trigger. But also on the other side of the Argument I feel at times the projects want to much, they want your Computers, want you to pay for the Electricity, want you to Donate money to their Projects, they even want you to volunteer your time to help recruit more people into their little tangled web of Credit Inequity. I can still remember running SETI Classic for 1 Credit for 1 Wu & was perfectly happy with it. It made me get faster Computers or Over Clock the one's I already had to speed them up so they could finish the Wu's faster & I could get that Precious 1 Little Credit faster ... haha Now people just want more credit because they see somebody else with a newer or faster computer getting more credit than they are with no effort on their part to try & improve their Computer or Computers, that's whats called wanting something for nothing. Oh how I long for the good old days of 1 Credit for 1 Wu over all this sandlot credit bickering ... :P |
Send message Joined: 7 Sep 07 Posts: 444 Credit: 5,712,523 RAC: 0 |
At least we've been reasonable about it! Not true for everyone unfortunately :) As for the rest of your post, I'm amazed how similar we feel about things!
Yeah, and when you happened to get a short Seti classic WU it was just a lucky break. That's where projects with fixed (or nearly fixed) crunch times per WU are nice. Same credit per WU - if you have a fast host you get more credits because you do more WUs. [tongue in cheek] Hey there we go, maybe Boinc should insist that all projects must have equal crunch time WUs! [/tongue in cheek] Applies flame retardant... |
Send message Joined: 29 Aug 07 Posts: 486 Credit: 576,548,171 RAC: 0 |
Hey there we go, maybe Boinc should insist that all projects must have equal crunch time WUs! Yes, that would probably make the Cross project Parity much more easier to implement. Buuuutt I doubt it would make the Group of People with the Idea that if I crunched 10 Hours on a Wu while my Wingman only crunches 2 hours then I think I should get 5 Times as much Credit for the same Wu as he got think any different ... :P |
Send message Joined: 27 Aug 07 Posts: 85 Credit: 405,705 RAC: 0 |
Hey there we go, maybe Boinc should insist that all projects must have equal crunch time WUs! Equal crunch times does not work for the science on the various projects. CPDN cannot work with less than several weeks per task without sending hundreds of Mega Bytes in intermediate results around. Some projects make more sense with tasks that an hour or less. Since the science is more important than eualizing crunch times, this idea doesn't work well. Even within a single project some of the crunch times will vary a great deal. LHC has some tasks that run to a maximum of 100,000 turns where others take 1,000,000 turns. S@H has different angle ranges in the data (how much the telescope was moving). BOINC WIKI |
Send message Joined: 7 Sep 07 Posts: 444 Credit: 5,712,523 RAC: 0 |
Equal crunch times does not work for the science on the various projects. Rest of post trimmed off. John, you gave good reasons for not having equal crunch times here, although I would like to say that I was by no means seriously making the suggestion. I was just poking some fun at the whole argument for and against cross project parity that this thread has been having lately. I quote from my own posting:
I'm glad it didn't trigger a bad reaction! Regards Rod |
Send message Joined: 27 Aug 07 Posts: 85 Credit: 405,705 RAC: 0 |
Equal crunch times does not work for the science on the various projects. Sorry, I looked at the post in the middle that had lost the tongue in cheek part. BOINC WIKI |
Send message Joined: 7 Sep 07 Posts: 444 Credit: 5,712,523 RAC: 0 |
Sorry, I looked at the post in the middle that had lost the tongue in cheek part. No problem, that's what I guessed had happened. I've been caught out like that, too! |
Send message Joined: 24 Dec 07 Posts: 1947 Credit: 240,884,648 RAC: 0 |
Milkyway gives less credit than an optimised SETI app on my E6850. |
Send message Joined: 30 Aug 07 Posts: 125 Credit: 207,206 RAC: 0 |
{cough} From Eric J. Korpela: SETI@home has been granting about 15% more credit per cpu second than comparable projects. Other projects have threatened to increase their own credit multipliers to compensate. The problem is that they all have different ideas about how much credit we should be granting. One project has threatened to give 50% more credit per second than the benchmarks would indicate they should. So to avoid the coming credit war, BOINC is implementing this credit multiplier BOINC wide. This will be an objective way to make sure that projects don't grant too much credit. In other words, this will (probably) be happening at most every cpu intensive BOINC project. Read the rest yourself, just pointing out the obvious. ;-) {cough 2} From the same post: Q. Does this mean SETI@home will grant my machine fewer credits than <other BOINC project>? waits for the uproar... Jord. The BOINC FAQ Service. |
Send message Joined: 22 Mar 08 Posts: 65 Credit: 15,715,071 RAC: 0 |
|
Send message Joined: 27 Aug 07 Posts: 46 Credit: 8,529,766 RAC: 0 |
From Eric J. Korpela: With this new multiplier, exactly what will they level out among the projects? Credit given to the slowest application version (typically 32-bit Windows/Linux)? Credit for the fastest version (typically 64-bit Windows/Linux)? Some sort of average credit per amount of time for the overall project? And what about exceptional applications like GPU clients, custom optimized applications etc. As I understand it, there will be 1 correction factor for the entire project, and not per host? Correct? If so... won't projects with lots of "optimized Boinc clients" (style 5.5.0, 6.1.0 etc) get a correction factor that pushes "regular" clients even further down the credit line? Just looking for some explanation on the new Boinc correction factors. Maybe best start a new thread about it? A fireproof thread :p BOINC.BE: For Belgians who love the smell of glowing red cpu's in the morning Tutta55's Lair |
Send message Joined: 29 Jul 08 Posts: 267 Credit: 188,848,188 RAC: 0 |
I'll answer that one: Money or rather the lack of money available to Seti as Seti relies on private donations/funding exclusively, The optimized apps are not a form of cheating or whatever, They are just able to better tailored to each cpu type, For example there's support for: SSE2 or SSE3 or SSSE3x or SSE4.1, As there is one for each. I've used SSSE3x in My 4 Quads(AK_v8 Seti app) and It produces valid results, Just faster than the stock 5.27 Seti app, This is assuming that nothing is wrong with any hardware or software of course. |
Send message Joined: 4 Dec 07 Posts: 45 Credit: 1,257,904 RAC: 0 |
The project operators should always have the power over their projects and this includes the granting of credits. I like the credits granted here (And I really liked them in the past), but this is not the only project that I crunch for. I currently have one on climate prediction.net that is currently over 6 million seconds completed and is at only 77% done. They grant only 311 credits per timestep (25920) which takes my computer about 13.5 hours to complete. The higher credit offered here at M@H makes up for that lost on other projects. I could have my dual core process only M@H and rake in almost 2400 credits per day, but I like doing other projects. Leave the credit system alone and let the projects get by on the merit of the project. By the way, does anyone know what is going on at the RieselSieve project. I haven't been able to get in contact with them for a couple of months. |
Send message Joined: 29 Aug 07 Posts: 486 Credit: 576,548,171 RAC: 0 |
Leave the credit system alone and let the projects get by on the merit of the project. I agree, except the problem is that a lot of the Projects never had any Merit to begin with other than to Fatten up your Credit Count if thats what you were after. Xtreme Lab was 1 such Project with other Projects taking it's place since it folded it's Credit Mill for the time being anyway. |
Send message Joined: 29 Jul 08 Posts: 9 Credit: 100,721,007 RAC: 0 |
@John-- I'm sorry you think mine is bigger than yours, but I refuse to cut it off. |
Send message Joined: 27 Aug 07 Posts: 85 Credit: 405,705 RAC: 0 |
The project operators should always have the power over their projects and this includes the granting of credits. I like the credits granted here (And I really liked them in the past), but this is not the only project that I crunch for. I currently have one on climate prediction.net that is currently over 6 million seconds completed and is at only 77% done. They grant only 311 credits per timestep (25920) which takes my computer about 13.5 hours to complete. The higher credit offered here at M@H makes up for that lost on other projects. I could have my dual core process only M@H and rake in almost 2400 credits per day, but I like doing other projects. Leave the credit system alone and let the projects get by on the merit of the project. It is designed to remove a burden from the project administrators. BOINC WIKI |
Send message Joined: 29 Jul 08 Posts: 6 Credit: 10,991,883 RAC: 0 |
I actually wish all projects used optimized apps. Or that BOINC had the built in ability to pass different apps to different CPU types. It seems such a waste to have a brand new SSE4 machine that isn't even using SSE2 because the project's apps have to remain backwards compatible with old processors. |
Send message Joined: 27 Aug 07 Posts: 85 Credit: 405,705 RAC: 0 |
I actually wish all projects used optimized apps. Or that BOINC had the built in ability to pass different apps to different CPU types. The ability to distribute optimized applications to BOINC clients based on what the OS reports is being worked on and is expected in 6.4. BOINC WIKI |
Send message Joined: 9 Jul 08 Posts: 85 Credit: 44,842,651 RAC: 0 |
Well, it took a LOT of reading on various boards, but I think I at least have a basic understanding of how this newer "automatic" credit calculation is supposed to work... I'm sure I'll get plenty of argument on this, but I have to say that it sounds pretty workable to me, if for no other reason than it will allow pretty much any project admin/scientist to "set it and forget it" once the project gets out of the very early alpha stage. (they need a sample of ideally a few thousand returns (or trickles for really long tasks) to do the math necessary) I've heard folks worry that the value of credits will deflate (or inflate depending on how you view it) with time, but no... from looking at their methods, it looks like a processor I buy a year from now that's 50% faster will earn credit about 50% faster. Okay, I know how everyone hates the benchmarks in BOINC, but most of the benchmark problems are isolated (buggy client release, benchmarks running when other programs are occupying the machine, etc.) and since this credit figgerer thingy uses a median benchmark from thousands of machines, the erroneous benchmarks get chucked out. Personally, I think that's a decent way to use benchmarks without their usual associated problems. If I were to simplify the whole thing as much as possible it sounds like they're taking this approach: Take all the benchmark results from thousands of machines... Mix in the result times from thousands of workunits... Shake liberally... Pour out an average granted credit per task based on the above. I *think* the actual application still has to report a fairly accurate count of total operations for the task if the project is going to use a 'claimed' credit system, but I'm not totally positive on that part. Perhaps it can either compute a multiplier for claimed OR an average that will simply be granted. I've yet to get into that level of detail. It looks to me like this is a good way that I can assure myself that if I stick my trusty P4D or Athlon on project A and it pays me 30k credits in a month, I can stick it on project B and it's going to pay me about 30k credits the next month without the project admins at either project having to do a darn thing. If it works like that, am I wrong to think that's a good thing? I've heard lots of discussion about projects that require a relatively extreme amount of RAM or storage or require low latency, etc. and I'm *guessing* the new system will still have manual adjustments to take those into account, but frankly, this project doesn't require anything unusual and none of the projects I've participated in have either (with a few very brief exceptions usually due to beta issues). I guess I've come to accept that no credit calculation system will be perfect for every project all the time, but from what I've read it sure seems like this system will be quite adequate for the projects that represent at least 97-98% of all the work done by all clients. Am I missing something fundamentally "bad" about this system? If so, can anyone tell me (in simple terms please...) what it is? |
Send message Joined: 27 Aug 07 Posts: 46 Credit: 8,529,766 RAC: 0 |
@Thunder: Thanks for the explanation. If that's the way it works, then I see following elements that can mess up, or at least distort, the correction factor for a project. I assume the project in the example does *not* use benchmark based credits: - If it has (own or 3rd party) applications optimized for specific platforms, then these clients will have a low claimed credit/granted credit ratio. If these clients are in the majority, then the majority of clients will be considered to underclaim. Or in other words, the project will be considered to be overly generous. The project credit will be corrected downward. That means that older machines, or machines for which no optimization exists, will get less credit than in projects without optimized applications . - If a project on the other hand has lots of optimized Boinc clients (style 5.5.0, 6.1.0), then these will have a high claimed credit/granted credit ratio. These overclaimers will cause project credit to be corrected upward. So... in theory the new calculation would make it interesting for a project to have lots of optimized Boinc clients... Mmmmm, the irony. My reasoning might be completely wrong. Any of the Boinc guru's can correct me? Starting to hold my breath in 1... 2... 3... BOINC.BE: For Belgians who love the smell of glowing red cpu's in the morning Tutta55's Lair |
©2024 Astroinformatics Group