You are correct a better way to do this may be needed for projects with multiple classes of tasks. The other way should still be good for projects where there is less variation in task complexity. I sent an email to the developer's list pointing to this thread.

Just a fun thought, what if Seti finds extraterrestrial life and its goal is achieved? (Finds over remaining out of work because it's only natural that other life forms exists up or down there)

Where would all those users divert their computing power? Oh my... Yes...

No, because most the members would not even notice they had ;-) Also there are always more ET type things to find.

Tried to reset the debt to 20, but it bumped right up to 3.5 million when I started BOINC again.

I,m running Fightaids@Home, which seems to be running as a independent project program that I had downloaded from the world community Grid site.I'ts running in the background along with Rosetta. There does not seem to be a noticable slow down on my processors.If I'm loosing rosetta credits so be it.

meeting scheduled for thursday next week. I'll be away for the weekend but I'll put together a doc that I'll take with me with the proposal etc.

Has anyone got any firm details on the AD install and connection process? I assume that the sensible way to run it would be to run it under it's own specific account with minimal priveledges? What read-only and write access to other folders would BOINC need - e.g. Windows folder or just its own? I might be going overboard but I'd rather be able to lay any fears to rest on the spot!

Network utilisation I think i'm on top of - need to check that info about proxies in the latest versions - thanks FC.

Yes, let the rest of the debt system etc. work out the details down the road. My understanding is it waits until a checkpoint is reached. So, may not be a completed model or completed WU... but means that no work is lost, even if you aren't keeping in memory or turn off the machine!

Simple way to extract maybe 5% more useful work out of the existing machines. Depends up often you end BOINC or were losing work that hadn't been checkpointed.

If anyone has a link to the details of this upcoming BOINC feature, please post a link.

Also resource share dictates how much of your CPU time to give to each project over the long term. Example. Project A share 50 and Project B share 100. Project A will have the CPU 1/3 of the time and Project B will have the CPU 2/3 of the time. If possible, it will be 2 hours of B and 1 of A (depending on the switch time). If one of the projects has anticipated deadline trouble, that project will get extra CPU time now, but will not be allowed to download new work for some time in order to let the other project catch up on its CPU time.

Thats pretty cool, I didn't know that. I just set one of my rigs onto 3 smaller projects to run for probably a year without me being able to touch them.

Thank you.

I was the developer that did most of the work on the current CPU scheduler.

Cool. Can you confirm that the 5.5.x versions switch only after a checkpoint and try to finish a WU before switching if it is near completion?

Well phooy. I guess I'll just crunch Rossetta by itself then.

With BOINC 4.x I could suspend the project then exit BOINC and a checkpoint would be forced so that on restart the current model would begin where it left off. On BOINC 5.4.9 I've noticed that this doesn't always work. Seems to be a flakey bug in it.

Luckily, it looks like the cross project parity is a non-issue. The new system grants what appears to be in the range of parity with others out there. Since no work needs to be done by the project to modify the new system, I don't see what is left to discuss on this topic.

http://boinc.bakerlab.org/rosetta/forum_thread.php?id=2164#23996

I was here back in the beginning, where it actually was a challenge to crunch Rosetta WU's. There was the 1% bug, the stay-in-memory-while-preempted bug, the freeze bug, other kind of bugs, and we had to tweak our settings just to be able to return valid results. Numerous was the times I had to exit my BOINC manager and start it again, sometimes even reboot my computer, in my attempts to "jumpstart" a frozen WU. It became a little easier when the graphics were developed (I still remember my first graphic WU. I had the graphics open all the time and I actually sat and looked at it from start to upload), as we then could see if a WU was alive or not, so we didn't have to abort a WU which seemed stuck. I remember the "Christmass bug", the flawed WU's that was sent out just before the devs left for their seasons holiday, so they were sent out all 11 times, as there was no devs there to kill them.

If anybody here dares to question my dedication to this project based on my RAC, I have only two words to say to that person, and that is not "Merry Christmas"!

The credit aspects as well as the science aspects of the application has to be closed.

I agree with that, but it's just a case of moving any benchmark/credit system out of the open BOINC app and into the closed science one. (Maybe we're getting confused over what we refer to as 'BOINC'?) There is no reason why a system using BOINC can't be made secure - as you say, it just requires any credit calculation to be removed from the open source bit (ok- there's a bit more to it than that as the current thread at Ralph is discussing, but in principal it's as stated).

cheers
Danny

But Danny: The Boinc Purits dont want that. When I proposed that very simple solution all I got was ..."BOINC is open source, end of discussion"

And even the science can be compromised. It was claimed here by some of the Boinc Purists that in SETI the science was tampered with. I have to take their word as valid or were they lying?

BTW I am going to be away from the computer for a while . Jury Duty Summons . So If I dont answer you it is not becase im not interested in engaging in a dialogu with you. It is becasue there is a good chance Toay I will be sequestered. Okes I dont want any clebrations on that :) ( Yes the rablerouser has a sense of humor)

It's known that a given simulation within a WU will vary. However, this variability will be both within a single WU and all the others of the same type. By definition, the credits will be based on the average of these results. Since it's not possible to know in advance how long each decoy will take, it should average out.

The other side of it is one WU type may grant slightly more or less credit than others. They're trying to keep that to a minimum, but as they've posted, they have tools to find people who take advantage of the system with this method.

Once the average credit/decoy is calculated, it's entirely dependant on how fast a given machine is. If Intel cpus can do more science in an hour due to features of its hardware, it will end up getting more credits (and vice-versa).

I know the results for any decoy will be an average of the decoys for that entire workunit type. But this is exactly what bothers me. Although the results will even out across the workunit they won't even out on the same machine. Some people will generate less decoys than others for the same workunit in the same amount of time possibly based only on their random number. I have seen this on my own machine after doing the same workunit downloaded multiple times. Users who have the bad luck of getting these long decoys will think it is unfair that someone with the same machine gets more credit for the same workunit for the same amount of time. And if I downloaded a whole 6 workunits at once and they end up being the same workunit and it grants a bit less credit than other workunits I would be forced to either be happy with getting less credit for all of them or to dump all of them. These are the two main issues I want resolved and I don't see that happening with the current system.

John did you read my post at all ? WCG through Boinc ?

Thanks...I should have figured that you would be the one to answer the question!

Assuming that the project will be put on one computer how long does it take to update?

Thanks
citroja

Also resource share dictates how much of your CPU time to give to each project over the long term. Example. Project A share 50 and Project B share 100. Project A will have the CPU 1/3 of the time and Project B will have the CPU 2/3 of the time. If possible, it will be 2 hours of B and 1 of A (depending on the switch time). If one of the projects has anticipated deadline trouble, that project will get extra CPU time now, but will not be allowed to download new work for some time in order to let the other project catch up on its CPU time.

Thats pretty cool, I didn't know that. I just set one of my rigs onto 3 smaller projects to run for probably a year without me being able to touch them.

This solution bears directly on the cross BOINC comparison issue. The credit per for a given computer should be the same no matter which BOINC project is being worked on.

Cross Boinc Comparison on one side vs Intra Project Fairness on the other.

Sorry John: Intra Project Fairness wins in my book all the time.

I dont have time to read every message everywhere, but I havn't seen this recommended yet. Why not go with the system of measuring credit done based on cpu and performance as planned, but instead of lowering scores, set the benchmarks up to be equal to what the optimized clients do now.

As far as I know, it was never against the rules to be using an optimized client, so instead of punishing the people who have, instead use those levels to set the standard of what a WU is worth, and take the data back to february to RAISE everyone up to an equal level, instead of lowering everyone to an equal level.

The only problem left here is that credits will be worth more then other boinc projects, but this is an independant project that can measure its work however it wants. Statistic sites will just have to skew results as they see fit.

I hope this makes sense, and really wouldn't piss people off or have issues with a second data column or separate scoring.


Edit - I've read that credits wont be backdated whatsoever, but this idea could still apply towards future credits. Multiproject parity isn't as important as equality within a project.