But since ppl often compile the source for their particular OS, couldnt they could choose to rewrite the credit code? (unless he plans not to release the source and limit the platforms the server can run on)
Example, what would happen if I started a project with his new creditnew server, and just rewrote his code back to the old system?
Last edited by DAD; 10-26-11 at 03:53 AM.
No, the code is open source so you are correct. The thing is DA is in the process of eliminating the possibility of being able to add an alternate credit schema to the code by making other various essential elements of the code dependent on the CreditNew code.Originally Posted by DAD
Bottom line: In the near future if a project does not want to use CreditNew then they will have to do some serious rewrite of a good portion of the server code. Since many projects do not have the time/patience/skill to do that, CreditNew will be the de-facto standard.
I am sorry to say. But when that happens - I am gone. I will then spend my money on something else.
Proud member of SETI.USA since 28īth December 2005.
Joined old MB Dec. 28th 2005 - 5837 posts
Unfortunately I share your sentiment. I think many teams will suffer much as credit mongers/point chasers decide BOINC isn't worth the time and money and move on to other hobbies. That will be a sad day indeed.
I will be gone as well. I hate when 1 person decides that they want to control how other projects run. I can put the money that I spend on electricity to good use elseware......MORE BEER!
RETIRED. NO JOB. NO MONEY. NO WORRIES!
Crunched SETI Classic to the end.
SETI@home classic workunits
17,550
SETI@home classic CPU time 86,861 hours
Well it depends on why you are using boinc. Yes I like to chase credits, but I'm also in it for the science. It won't stop me from crunching, but it will change how I do it, and how many resources I devote to it. I dont want to penalize projects for DA's moronic thinking. However, projects can chose NOT to upgrade to his new code, but then projects may eventually fall behind or become non compatible with newer clients
However, if I ever ran a server, I WOULD rewrite his code as I do have the programming and math knowledge and time to do so.
... hmmm.. idea.... lol.. rewrite server code.. make that code available for public usebut that may violate some legal things. I need to look into the EULA for the boinc client/server. If it can legally be done, then I'll snag his new, mandatory, credit new server code, re write it, and put the files up for free for public use, and then each project can recompile it
In the end, if projects start really losing people over his new system, they will pressure him to undo it or seek/design another boinc-like client/server solution.
Nope you would not violate DA's license agreement. It's the limited GPL which allows for 3rd parties to change code. The only caveat is that DA gets the rights to your code. Trust me, if I had your skills or Buffet's money this whole thing would be a non-issue.Well it depends on why you are using boinc. Yes I like to chase credits, but I'm also in it for the science. It won't stop me from crunching, but it will change how I do it, and how many resources I devote to it. I dont want to penalize projects for DA's moronic thinking. However, projects can chose NOT to upgrade to his new code, but then projects may eventually fall behind or become non compatible with newer clients
However, if I ever ran a server, I WOULD rewrite his code as I do have the programming and math knowledge and time to do so.
... hmmm.. idea.... lol.. rewrite server code.. make that code available for public use
In the end, if projects start really losing people over his new system, they will pressure him to undo it or seek/design another boinc-like client/server solution.
For Collatz, I just let all the creditNew code run right before it updates the database, I change the credit value. The project thinks it is running the creditNew, but it actually uses the fixed credit. Unless DA changes it so that all credit is stored centrally, I don't think there is anything he can do to stop that from working. Projects that award credit according to GFLOPS and not some type of fixed credit will require a lot more code since DA has removed some of the estimated and client reported GFLOPS values returned with the workunits. The creditNew uses the time crunched along with the benchmarks to calculate the credit. Grabbing the GFLOPS from the database for that host and calculating the GFLOPS by using the compute time would work, but would be messy and require quite a few code changes.
Since AMD has stated that CAL/Brook will no longer work in future releases even though OpenCL favors nVidia, Collatz will need to support OpenCL even though OpenCL performance sucks compared to CAL. OpenCL either runs 50% slower, uses 100% CPU even when doing asynchronous calls, or both. OpenCL support will require upgrading to the latest server code, so I'll find out then how hard it is to still bypass creditNew at that time.
Spring 2008 Race:
(1st Place)
I have an OpenMP version of Collatz for CPUs that I tested. It is configurable form 1-N cores via the app_info.xml file, but it doesn't play very well with GPU apps and is a couple percent slower than running once WU per core (e.g. if a quad core box can run 4 WUs - one per core - in 20 minutes, the OpenMP version should be able to run one WU on all four cores in 5 minutes. In reality, it takes about 5 minutes and 6-8 seconds. So, you lose 6-8 seconds. On the other hand, you only have 1 WU to upload and report so it may balance out since BOINC doesn't grant any credit for time spent uploading, downloading, and reporting completed work since that's done by the BOINC client and not the app.
I haven't attempted to create a multi-GPU app yet since the fast GPUs can crunch a Collatz WU so quickly and since trying to keep GPUs of different speeds all busy is not easy. If they were all the same speed, one could divide the WU by the number of GPUs and run part on each. When the GPUs are different speeds and/or the PCIe slots don't transfer data at the same speed, one GPU will finish before another and then there is wasted idle time which means fewer credits than running one WU per GPU.
Posting Permissions
Reply With Quote
