Cobblestones

Obviously there are different ways to grant credit to you guys. It has been long debated on how that should be done.

One method takes into account time, it you take more time on a workunit, you get more credit. This however gives advantages to slow machines. They are doing less work yet getting more credit.

The other approach is FLOPS. you are granted credit based on total FLOPS of an application. This would favor fast machines over slow ones, as they have a higher throughput.

There is also a hybrid of the two, basing it on the speed of your machine, the total FLOPS and the time taken.

Personally I think throughput is the bottom line. And credit should be assigned by the size of the workunit in FLOPS. But in the spirit of democracy we will elect a method to compute points.

Here is how it will go. In the first round every member is entitled to propose how the credits will be granted.

We will then take a vote on the one you guys like the best. We well then use that scheme in assigning credits.

Remember that the proposals should be for what to base the credit on and not how much credit to give.

For example:

Credits = total flops / flop rate

is ok.

But

Credits = 1 gazzilion per work unit

is not ok.

Hope this works out, have fun. Proposals will be open until Sunday night, we will vote on Monday.

Well... I will be the first to kick off here.

My vote goes to the Flops, because in my eyes this is the most "honest" approach. A quorum off 3 would be nice.
It provides credits based on the work done.

Static credit would be my second to best... and isn't that bad while being in "alpha" stage. A point extra would be to keep the credits/hour in pace with the other projects.

To be honest... let's not fall into the pitthole of credits based on benchmarks.
Or worse a combination of bechmarks with a quorum of one.
(BOINC) History has had it's flame wars based on various ways to "spoof" credits based on such an approach. I would hate to see a fine project like Docking going to wast.

Just my 2 cents... ;-)


____________

I'm quite with Rene.

I'd prefer fixed or server-side calculated Credits if possible. "Possible means either all WUs have roughly the same size (for fixed credits) or a pre-known variable size (server-side calculation).
Flops should be the next best thing, not much behind.

Benches should only come with a quorum, which itself should only come if necessary for scientific purposes.
____________
Gruesse vom Saenger

For questions about Boinc look in the BOINC-Wiki

I support the same way of applying FLOPS as the project had taken before.

suguruhirahara
____________

I'm a volunteer participant; my views are not necessarily those of Docking@Home or its participating institutions.

> Have been away a few days.
I am probably too late for this vote and only three other people have voted.

The amount of FLOPS for a certain WU type, I assume will be a certain amount, no matter how long it takes to actually do that calculation.
Therefore FLOPS should give a fairly true amount for the effective work done on a WU type.
Of course the faster the machine the more work units can be done in a day an so the actual amount of points/credit/cobblestones that computer can earn will be more than a much slower one.

Benchmarks are so flawed as to not have any meaning, so I vote benchmarking out.

Set credit at the server is OK but you would need a reference machine to arrive at your base, as this can then give like machines to the reference machine an advantage over other cpu types and OS types, again I vote this one out if based on a reference machine.
If done via calculations to see what should be gotten, then this type of set credit would be OK and I would vote for it.

But overall FLOPS seems to be a more reasonable way to get points for the amount of work done.

(Now the amount awarded for each FLOP, well that will be another issue and another thread, and I bet far more responsive and possibly heated to this thread)
____________

I'd prefer fixed or server-side calculated Credits if possible. "Possible means either all WUs have roughly the same size (for fixed credits) or a pre-known variable size (server-side calculation).
Flops should be the next best thing, not much behind.

Benches should only come with a quorum, which itself should only come if necessary for scientific purposes.

I'd prefer fixed or server-side calculated Credits if possible. "Possible means either all WUs have roughly the same size (for fixed credits) or a pre-known variable size (server-side calculation).
Flops should be the next best thing, not much behind.

Benches should only come with a quorum, which itself should only come if necessary for scientific purposes.

+1

I also want to emphasize that increasing the quorum should be done only if the science requires it. Increasing the quorum purely for credit management is a horrible waste of resources. There's always a better way.

I'd prefer fixed or server-side calculated Credits if possible. "Possible means either all WUs have roughly the same size (for fixed credits) or a pre-known variable size (server-side calculation).
Flops should be the next best thing, not much behind.

Benches should only come with a quorum, which itself should only come if necessary for scientific purposes.

+1

I also want to emphasize that increasing the quorum should be done only if the science requires it. Increasing the quorum purely for credit management is a horrible waste of resources. There's always a better way.

If it is not too late here are my 2 cents...

If WUs are about the same size I think is better to have a static credit per WU. This gives little more work to the admins but I think at the end both volunteers and admins will be happier. Plus from my past experience with charmm being so crazy at times I remember Andre was able to control credit better this way, that is give similar credit than other projects.

Since the WUs will have variable length, credits based on FLOPS would be my choice.

Since the WUs will have variable length, credits based on FLOPS would be my choice.

I take it that the Project has caved into some sort of Credit Reduction already from looking at these Wu's on mine http://docking.cis.udel.edu/result.php?resultid=1770 = 50 Credits Per Hour reported in Feb 2008 to this one reported in Mar 2008 > http://docking.cis.udel.edu/result.php?resultid=7007 = 20 Credits Per Hour ... ???

Good point. No, I've not been able to figure out why these system calls to get the time of day on linux are made a gazillion times per run. I do think that this might cause the massive difference in runtime between linux and windows. The runtime difference issue is already on the project's to-do list, so I'll make sure that whatever notes I have on this will be passed on to the next person trying to crack this issue.

Cheers
Andre

Since the WUs will have variable length, credits based on FLOPS would be my choice.

I'd agree with FLOPS but when assigning the credit per flop, I'd keep in mind other resources being used. IIRC, charmm takes a lot more memory than some other projects and was very disk or OS call intensive. I'm not sure Andre ever found out what was going on with the heavy disk/OS activity. On Linux, it showed up as large amounts of CPU time spent in "System" space. ISTR that many quad core machines (Often Macs) experienced vastly increased time per WU as more cores were working on docking until it basically paralyzed the machine. That was being worked on when the project shut down for the move. It may even have been a bug that was subsequently fixed in the BOINC client. There seemed to be a massive number of calls to request the time being made to the OS. I don't recall if that was ever linked to re-reading the script that runs charmm and possible updating of the last-access time for the script file or if it turned out to be something else entirely.

Good point. No, I've not been able to figure out why these system calls to get the time of day on linux are made a gazillion times per run. I do think that this might cause the massive difference in runtime between linux and windows. The runtime difference issue is already on the project's to-do list, so I'll make sure that whatever notes I have on this will be passed on to the next person trying to crack this issue.

Cheers
Andre

I've emailed you the notes I could find. Hope they will be a little bit useful.

Andre

The problem of execution time differing between windows and linux need to be solved before we move on to fixed credit based on FLOPS. I will be working on this issue tomorrow. Andre, can you pass me the notes you have on this issue ?

cheers,
Arun

Andre wrote:

Good point. No, I've not been able to figure out why these system calls to get the time of day on linux are made a gazillion times per run. I do think that this might cause the massive difference in runtime between linux and windows. The runtime difference issue is already on the project's to-do list, so I'll make sure that whatever notes I have on this will be passed on to the next person trying to crack this issue.

Hmmm, that sounds interesting. Yes, please let the project team know if you find something on that. In the meantime, Arun could try commenting out the boinc calls in the charmm code and see if the time calls are still being made. If not, then that points in the direction you are thinking.

Andre

Do you know for sure if the problem still exists? Unfortunately, I don't remember the details but while docking was shut down there was a fix mentioned on the BOINC developers mailing list (might have been the forums) that sounded to me like it might have been causing a similar problem. It's been a long time so I don't recall if it was in the BOINC client or in the application framework that was distributed. Since it didn't affect most applications, it must have been in a support function or something. A polling loop with no delay in it that was calling the OS time of day function to check elapsed time was what it sounded like. Might have had something to do with a heartbeat function. I'll see if I can find it.

Hmmm, that sounds interesting. Yes, please let the project team know if you find something on that. In the meantime, Arun could try commenting out the boinc calls in the charmm code and see if the time calls are still being made. If not, then that points in the direction you are thinking.

Andre

Do you know for sure if the problem still exists? Unfortunately, I don't remember the details but while docking was shut down there was a fix mentioned on the BOINC developers mailing list (might have been the forums) that sounded to me like it might have been causing a similar problem. It's been a long time so I don't recall if it was in the BOINC client or in the application framework that was distributed. Since it didn't affect most applications, it must have been in a support function or something. A polling loop with no delay in it that was calling the OS time of day function to check elapsed time was what it sounded like. Might have had something to do with a heartbeat function. I'll see if I can find it.

So far, I haven't been able to find where I read it. IIRC, it was just a few months after Docking shut down at UTEP. I thought it was fixed at the time but I'm not sure on that and I can't find it in the archives or BOINC forums. You might have to ask on the BOINC DEV mailing list.

____________
The views expressed are my own.
Facts are subject to memory error :-)
Have you read a good science fiction novel lately?

The amount of credit granted on this project (particuarly for my Linux running Opterons at 8-10 cr/h) is not all that high, very low actually, as it is still based on the benchmark system.

Just wondering when can we expect the change to fixed system of FLOPS counting or whatever other system you are going with?

For the amount of hours/costs I am inputing I am not getting that much of a return.

Other than this problem, at the moment all is running well, xml data is exporting again, no more erroring work units so it's clear flying ahead (at least at the moment).

Conan

Keep smiling as it makes others wonder what you have been uo to.
____________

The amount of credit granted on this project (particuarly for my Linux running Opterons at 8-10 cr/h) is not all that high, very low actually, as it is still based on the benchmark system.

Just wondering when can we expect the change to fixed system of FLOPS counting or whatever other system you are going with?

For the amount of hours/costs I am inputing I am not getting that much of a return.

Other than this problem, at the moment all is running well, xml data is exporting again, no more erroring work units so it's clear flying ahead (at least at the moment).

Conan

Keep smiling as it makes others wonder what you have been uo to.

The amount of credit granted on this project (particuarly for my Linux running Opterons at 8-10 cr/h) is not all that high, very low actually, as it is still based on the benchmark system.

Just wondering when can we expect the change to fixed system of FLOPS counting or whatever other system you are going with?

For the amount of hours/costs I am inputing I am not getting that much of a return.

Other than this problem, at the moment all is running well, xml data is exporting again, no more erroring work units so it's clear flying ahead (at least at the moment).

Conan

Keep smiling as it makes others wonder what you have been uo to.

I just created a thread to update you all on the next steps to move (finally) to beta. The issue with the credits has change since we discussed it in one of our thread. Unfortunately each work-unit does not take a deterministic amount of time. This discourages us from using a fixed amount of credits. We have done major changes to the code of charmm, and now we use the same charmm source for Windows and Linux with the same compiler optizations. This should preven significant differences betweeen the Windows and Linux versions (that were observed in the past).

Sure we can increase the amount of credits per flops. Also we want to identify those volunteers who give us the best results. We are working on a web-page that classify the top results and its volunteers.

Our goal is to have D@H in Beta on September 1. We are moving forward!

Michela

For comparison, on this machine I am averaging 13.8 per CPU hour here, 15.3 per CPU hour at SZTAKI, 19.4 per CPU hour at Rosetta and 21.1 per CPU hour at Einstein and 33.8 per CPU hour at QMC. (Q6600 @ 2.4GHz, Win XP).
____________
Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.

For comparison, on this machine I am averaging 13.8 per CPU hour here, 15.3 per CPU hour at SZTAKI, 19.4 per CPU hour at Rosetta and 21.1 per CPU hour at Einstein and 33.8 per CPU hour at QMC. (Q6600 @ 2.4GHz, Win XP).

• Docking@home 14.63 cr/h
  
• World Community Grid 16.36 cr/h
  
• ABC@home 19.53 cr/h
  
• Simap 21.91 cr/h
  
• Einstein@Home 24.26 cr/h
  
• QMC 29.22 cr/h
  
• PrimeGrid 34.24 cr/h
  
• MilkyWay@Home 35.88 cr/h
  

----> more details and source stats from here .
____________
Bribe me with Lasagna!! :-)

For comparison, on this machine I am averaging 13.8 per CPU hour here, 15.3 per CPU hour at SZTAKI, 19.4 per CPU hour at Rosetta and 21.1 per CPU hour at Einstein and 33.8 per CPU hour at QMC. (Q6600 @ 2.4GHz, Win XP).

I have found quite similar results for my dual core lappy (T7700@2.4 Ghz) under Win x64:

• Docking@home 14.63 cr/h
  
• World Community Grid 16.36 cr/h
  
• ABC@home 19.53 cr/h
  
• Simap 21.91 cr/h
  
• Einstein@Home 24.26 cr/h
  
• QMC 29.22 cr/h
  
• PrimeGrid 34.24 cr/h
  
• MilkyWay@Home 35.88 cr/h
  

----> more details and source stats from here .

My puter has this C/h rates for various projects (decending order):
Project : C/h granted
Cosmology : 105,82
Milkyway : 97,44
PrimeGrid : 61,81
Einstein : 60,02
Riesel : 52,46
QMC : 42,81
CPDN : 42,99
GPUgrid : 39,71
yoyo : 37,21
Simap : 35,26
Tanpaku : 34,28
Magnetism : 30,80
Poem : 28,27
BURP : 26,12
Lattice : 26,31
UTC malaria : 26,45
Malaria : 26,19
Rosetta : 25,48
BCL : 25,51
Leiden : 25,44
ViP : 25,20
RALPH : 25,18
IberCivis : 25,00
WCG : 23,07
Docking : 21,15
LHC : 20,62
BOINCalpha : 20,25
GenLife : 18,94
Orbit : 18,09
Superlink : 10,11
Pirates : 9,22


____________
Gruesse vom Saenger

For questions about Boinc look in the BOINC-Wiki

For comparison, on this machine I am averaging 13.8 per CPU hour here, 15.3 per CPU hour at SZTAKI, 19.4 per CPU hour at Rosetta and 21.1 per CPU hour at Einstein and 33.8 per CPU hour at QMC. (Q6600 @ 2.4GHz, Win XP).

I have found quite similar results for my dual core lappy (T7700@2.4 Ghz) under Win x64:

• Docking@home 14.63 cr/h
  
• World Community Grid 16.36 cr/h
  
• ABC@home 19.53 cr/h
  
• Simap 21.91 cr/h
  
• Einstein@Home 24.26 cr/h
  
• QMC 29.22 cr/h
  
• PrimeGrid 34.24 cr/h
  
• MilkyWay@Home 35.88 cr/h
  

----> more details and source stats from here .

We definitely need to give you all more credits!!!

I will look at this today.

Michela

We definitely need to give you all more credits!!!

My puter has this C/h rates for various projects (decending order):
Project : C/h granted
Cosmology : 105,82

We definitely need to give you all more credits!!!

Yes, agreed.
The current ones are benchmark-depending because of quorum 1, that's a nice and easy way for cheaters to use optimized clients.
Think about some fixed credits maybe.

My puter has this C/h rates for various projects (decending order):
Project : C/h granted
Cosmology : 105,82

Obviously you haven't crunched Cosmo for a while, Saenger.
They fell down to a level under SETI! ;)

I claim considerably less than benchmarks would demand. It's quorum=1, but no benches.

I claim considerably less than benchmarks would demand. It's quorum=1, but no benches.

Hm, then why do your results always getting what they are claiming?
It's the same for me - claim = grant, so it must be benchmark-depending. ;-)
And I note down my WUs in an Excel-worksheet.
The average per hour for the last WUs was always the same. With fixed credits it would have varied. ;)

I've got claim=grant as well on Einstein and CPDN, both are not using benches like Docking. Only they both give me considerably more than I would claim with benches.
____________
Gruesse vom Saenger

For questions about Boinc look in the BOINC-Wiki

For comparison, on this machine I am averaging 13.8 per CPU hour here, 15.3 per CPU hour at SZTAKI, 19.4 per CPU hour at Rosetta and 21.1 per CPU hour at Einstein and 33.8 per CPU hour at QMC. (Q6600 @ 2.4GHz, Win XP).

I have found quite similar results for my dual core lappy (T7700@2.4 Ghz) under Win x64:

• Docking@home 14.63 cr/h
  
• World Community Grid 16.36 cr/h
  
• ABC@home 19.53 cr/h
  
• Simap 21.91 cr/h
  
• Einstein@Home 24.26 cr/h
  
• QMC 29.22 cr/h
  
• PrimeGrid 34.24 cr/h
  
• MilkyWay@Home 35.88 cr/h
  

----> more details and source stats from here .

We definitely need to give you all more credits!!!

I will look at this today.

Michela

Being curious, and since I have several "dual boot" machines, I took a look at benchmarks for the same machine on windows VS Linux. (note: all are 64 bit Linux boinc versions, The Windows benchmarks are 64bit except where noted and on AMD processors )

AMD 9950 BE Quad
Win 2231/7219 SUM=9450
Lin 2129/5252 SUM=7381

AMD 9950 BE Quad
Win 2235/7203 SUM=9438
Lin 2086/6043 SUM=8129

AMD64 X2 6000 Dual
Win 2879/7481 SUM=10360
Lin 2891/7465 SUM=10356

AMD64 X2 5200 Dual
Win 2567/6747 SUM=9314
Lin 2632/6345 SUM=8977

AMD64 X2 4800 Dual
Win 2586/4662 SUM=7248 (32bit windows)
Lin 2371/5998 SUM=8369

AMD64 3700 Single
Win 2316/4209 SUM=6525 (32bit windows)
Lin 2129/5252 SUM=7381

Since the formula for "claimed credit" = ((Whetstone + Dhrystone) x Cpu Seconds)/1728000 I also included the sum of Whet and Dhry. Meaning the only part left is "Cpu Seconds", which I'll now collect avg data on and see if Windows has an advantage over Linux.

Be back soon.

(note: NO intel data available
and all data taken from my publicly available list of hosts)

OK, I've collected all the wus that exist in the database for those machine/os combinations. I've found several very short wus (<1400sec) and deleted them from all records. Here's the average cpu seconds per OS, sample size, and "claimed credit per second" based upon the benchmarks in the previous post using ((whetstone + Dhrystone) x 3600)/1728000.

AMD9950one BE Quad
Lin, 3609 seconds/ (230 samples)/ 15.38 credit/hour based upon benchmark
Win, 3673 seconds/ (12 samples)/ 19.69

AMD9950two BE Quad
Lin, 3554 (236) 15.38
Win, 3584 (9) 19.66

AMD64 X2 6000 dual
Lin, 3292 (124) 21.58
Win, 3543 (11) 21.58

AMD64 X2 5200 dual
Lin, 3580 (108) 18.70
Win, 3622 (6) 19.40

AMD64 X2 4800 dual
Lin, 4029 (98) 17.43
Win, 4348 (5) 15.1 (32bit windows)

AMD64 3700 single
Lin, 4275 (18) 15.38
Win, 4185 (39) 13.59 (32 bit windows)

to be honest I'm not seeing a big difference either way. Looks like I should run linux on some, windows on some. Linux generally is faster per wu but claims less/hour. Draw your own conclusions.

I vote 33.8 per CPU hour like QMC. (Q6600 @ 2.4GHz, Win XP

Just a thought..
____________

Hi All, we are discussing about this item (increasing the credit), but we have some concerns. One is that if we increase the credit much, we will attract the kind of volunteers that do crazy things with the code or with the machines (malicious sw modifications or overclocking) just to gain more credit, even to the price of returning us bad results. Although we are using a strategy to validate, we don't want to go back to the use of HR and things like that, because as you know it results in longer times to get the credit and discrepancies between the claimed credit of one user and other, which ultimately means less credit for many users.

We need to find a value for the credit that is beneficial for you but does not attract malicious users, as I just told you, we are trying to find a solution, so keep tuned, I'll let you know as soon as we have an agreement

edit: let me correct my words, I never meant users that just have fun with the settings of their computers or compete with each other for credit, that is part of VC and bring to life projects like this. I meant malicious attackers that tamper with the BOIC mechanisms of the credit system, which at the end results in unfairness for the VC comunity

have you all seen project comparison like the one done by Boincstats? project credit comparison . Doing a quick count before my first cup of joe shows that out of the 50 projects listed, 25 pay more than Docking and 24 pay less than docking(might wanna recount for yourselves). Don't know what you/others can make out of this, or even how they come up with these numbers. Also, there's a comparison done by "allprojectstats" but can't find a link ATM.

Ofcourse instead of doing it that way, you could find the median score by adding the value of every quantity under the "Docking" column. That yeilds 79, then subtract the freakish 17.95 of PS3Grid and you get 61.05. Now divide that by the number of projects 50 minus PS3grid = 49, minus yourself which didn't add the 1 into the total and you get 48 projects, so 61.05/48 = 1.27. So the median is 1.27 or a need for a 27% increase. If you went this way, then you wouldn't be in the middle anymore.

Aren't numbers cool, you can twist them any way you want.

tony
Heck, just didn't know if you'd seen it or even if the numbers from Allproject stats comes out differently.

tony

The site I usually see mentioned when project admins are talking about cross-project-parity is at

http://boinc.netsoft-online.com/e107_plugins/boinc/get_cpcs.php

I think that site has a bit more recent snapshot of the credit situation and seems to show changes fairly quickly. Here's a few examples from todays numbers:

SETI: 1.000 (Always 1.000 - the standard for comparison)
Rosetta: 0.891
Docking: 0.727
WCG: 0.841
CPDN: 0.905
Malaria: 0.907
Lattice: 0.972
POEM: 1.172
Superlink: 1.020
Einstein: 1.162
Primegrid: 1.173
SIMAP: 1.382
QMC: 1.548
Milkyway: 1.908

The numbers have been gradually moving lately with many projects getting closer to SETI.


____________
The views expressed are my own.
Facts are subject to memory error :-)
Have you read a good science fiction novel lately?

The problem with SETI = 1 is that there is no way from the exported xml stats to see who is and who is not using an optimised science app, core client, or both, (and if they are, which ones).

A further problem is that not all projects have the same demands. Should a project that crunches for an hour, using 20k of memory, 5 disk writes of 80 bytes and a wu download size of 20 bytes give the same credit as one that crunches for an hour, needs 500M memory, writes 50k checkpoints every 3 seconds and has a wu download size of 60M? How about another one with one hour wu's and other figures the same as the first example above, but 1 wu in 3 fails?
____________
Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.

Dear Admins and project managers.

For over 4 years now I have had this nice hobby that I can work on at home. It’s called distributed computing. And in just the last year the fun and excitement has started to dwindle down to whose going to start a peeing match with whomever over wu credits. And then I see this post by your project manager listed below.

>>> Hi All, we are discussing about this item (increasing the credit), but we have some concerns. One is that if we increase the credit much, we will attract the kind of volunteers that do crazy things with the code or with the machines (sw modifications or overclocking) just to gain more credit, even to the price of returning us bad results. Although we are using a strategy to validate, we don't want to go back to the use of HR and things like that, because as you know it results in longer times to get the credit and discrepancies between the claimed credit of one user and other, which ultimately means less credit for many users.

We need to find a value for the credit that is beneficial for you but does not attract those users, as I just told you, we are trying to find a solution, so keep tuned, I'll let you know as soon as we have an agreement<<<

1. Let’s start by telling you that I have over $30,000 dollars in computer systems, of which I removed off of your project just as soon as I saw this Posting above.
2. This statement refers to folks such as me, as scum of the earth in its relayed meaning, just because I want to have fun with my hobby and bragging rights to how fast I can make my computers run and still be stable.
3. People like me and teams that think like me are getting a little ticked off from everyone who just wants us to run stock equipment and stock applications.
4. When projects start paying for our computers and we want to sell the computer time to them, then and only then will I cow down and do as you say.
5. The concept of distributed computing is to use volunteers’ computers to get work done for the betterment of science and mankind. The operative word here is Volunteers.
6. And those of us who try and have fun and get the work done correctly and faster are being put down for our efforts and our goals.
7. Well folks somewhere down the road you will run us off until there is no longer any reason for us to participate.
8. The project admin’s will all have the same credit and all of the projects will be run by the zero crew.
9. What a perfect world you will have then.

Take care and good luck on your project.

DD,

____________

Hi All, we are discussing about this item (increasing the credit), but we have some concerns. One is that if we increase the credit much, we will attract the kind of volunteers that do crazy things with the code or with the machines (sw modifications or overclocking) just to gain more credit, even to the price of returning us bad results. Although we are using a strategy to validate, we don't want to go back to the use of HR and things like that, because as you know it results in longer times to get the credit and discrepancies between the claimed credit of one user and other, which ultimately means less credit for many users.

We need to find a value for the credit that is beneficial for you but does not attract those users, as I just told you, we are trying to find a solution, so keep tuned, I'll let you know as soon as we have an agreement

Hi zeitgeistmovie.com,

I never said to give you guys LESS credit!! I woudn't even dare to say that without first hiding myself in the most obscure place in Earth. No, I was saying that when a project uses redundancy it usually grants less credit to half of the participants because it has to perform an average over a set of claimed credits for the same workunit (usually removing the highest and the lowest), so if you are claiming 20, but the average says 15, you will receive 15. Right now, the way in which we are working is: if you claim 20 you receive 20. Just to make this point clear, we are discussing to give you MORE credit, not less.

Now, going back to the overclocking, many of the scientific applications that projects like us are running are chaotic applications, that implies that very small divergences result in completely different results. With overclocking there is the risk that one of the millions of floating point operations that are executed per workunit flip a bit. This flipped-bit, if occurs sooner in the execution of the wu will carry an error that will accumulate over the time, so, at the end of the wu execution we might have a useless result. That is basically the main problem with overclocking and also some sw modifications. Not all the overclocked machines will have the problem, but some of them will

Regards

Dear DD,

First of all, I didn't mean to offend you. I'm so sorry if I did and I apologize. The same is to anybody else who feels this way. That was not my intention.

Second. we don't want to interfere with your fun, not at all. If you are able to do as you say: run your computers faster and still be stable , then do it, we are happy with that

Hi All, we are discussing about this item (increasing the credit), but we have some concerns. One is that if we increase the credit much, we will attract the kind of volunteers that do crazy things with the code or with the machines (sw modifications or overclocking) just to gain more credit, even to the price of returning us bad results. Although we are using a strategy to validate, we don't want to go back to the use of HR and things like that, because as you know it results in longer times to get the credit and discrepancies between the claimed credit of one user and other, which ultimately means less credit for many users.

We need to find a value for the credit that is beneficial for you but does not attract those users, as I just told you, we are trying to find a solution, so keep tuned, I'll let you know as soon as we have an agreement

Hi All, we are discussing about this item (increasing the credit), but we have some concerns. One is that if we increase the credit much, we will attract the kind of volunteers that do crazy things with the code or with the machines (sw modifications or overclocking) just to gain more credit, even to the price of returning us bad results. Although we are using a strategy to validate, we don't want to go back to the use of HR and things like that, because as you know it results in longer times to get the credit and discrepancies between the claimed credit of one user and other, which ultimately means less credit for many users.

We need to find a value for the credit that is beneficial for you but does not attract those users, as I just told you, we are trying to find a solution, so keep tuned, I'll let you know as soon as we have an agreement

I agree with the issue of modifying the software application. If the project starts allowing or promoting "optimized" apps without project testing and acceptance, then I will leave. I do not run any projects that allow optimized apps that are not under project control.

I agree with the issue of modifying the software application. If the project starts allowing or promoting "optimized" apps without project testing and acceptance, then I will leave. I do not run any projects that allow optimized apps that are not under project control.

Hi j2satx,

Users cannot recompile our application, so, they cannot run an optimized version of it. About your resources, we haven't had any complain with your results, when we get invalid results we usually send an email to the owner of the host.

Hi Nite Owl, thank you for the correction.

In that case, I'm not sure, I will ask and let you know.

I agree with the issue of modifying the software application. If the project starts allowing or promoting "optimized" apps without project testing and acceptance, then I will leave. I do not run any projects that allow optimized apps that are not under project control.

Hi j2satx,

Users cannot recompile our application, so, they cannot run an optimized version of it. About your resources, we haven't had any complain with your results, when we get invalid results we usually send an email to the owner of the host.

I'm sure j2satx was talking about optimized BOINC application, not your project app... Optimizing BOINC can indeed increase the amount of credits received when using the Benchmark criteria...

I don't understand why there has to be this big difference between my 'puters with different OS when I compare them up against the formula "claimed credit" = ((Whetstone + Dhrystone) x Cpu Seconds)/1728000??
I get granted 106% when I use the PC with Windows Vista 32bit (granted 11,08 per hour, the formula gives me 10,40/hour). Then I have one with Linux Ubuntu 32bit - and I get only 91% (granted=12,62 - the formula gives 13,74), but the worst case is the two computers with Linux Ubuntu 64bit :-(. They give me 79% !!! - (the first one - granted 14,95 - formula=18,75, and the other one gives granted=18,95, the formula gives 23,91)
Again - why???
Is the Windows32bit-system much more effective? If we want to have the most effective DC-community world wide, then all of us have to use our computers were they do most work - then we will get more work done with less power - (anyway that is just my opinion). That's why I have to ask if this differences between the credit granted to the different OS, is showing us that Windows 32bit-system is much more effective than Linux 64bit-OS ?? Can I assume that my Linux 64bit-'puters' will do a better job elsewere, and they are not efficiant enough here at Docking??
Or - is there another explanation?

Have found time to post some averages for my machines

(bear in mind that I take total computational time I have provided (i.e. includes all work done, successful or not) and the total granted credit given by the project (includes zero credit jobs) as the basis for my calculations. The reason is I have donated this computational time and compare it to the credits I have in return for this donated computational time).

I will use 2 machines for comparison as both have the same processor, M/Board and RAM (AMD Opteron 285), one has Windows and one has Linux

[list]
Project 285 Linux 285 Windows

Cosmology---- 22.45---- 28.93
Docking------ 12.79---- 16.33
Lattice------ 11.72---- 18.13 (normally 13.74)
LHC---------- 15.59
Rosetta------ 14.52---- 10.67 (was around 14)
Ralph-------- 11.95---- 13.14
QMC---------- 29.59---- 16.49 (normally over 23)
Superlink---- 15.10---- 18.00
Hydrogen----- 0.00----- 20.68
MilkyWay----- 0.00----- 26.00
SpinHenge---- 9.63----- 16.26

Seti I only do on a AMD 4800+ and it gets around 20 with an very old optimised app which is now not very much different to a stock app.
I have not included Optimised apps in this sample.
MilkyWay figures are for the normal app not the new optised app.
Some figures are a few months old but all over the last 6 months or so.
Lattice result in Windows influenced by a 204 hour Garli WU.
Cosmology on Windows has also dropped since this sample was done so closer to 22 than 29.
No current data for CPDN and Einstein.
If I was able to get the same output for Linux as I get for Windows I would have a much higher RAC on nearly all projects.

Docking is very much lower than most projects I do, Particularly on Linux.

The figure I get on the AMD 4800+ for Docking is 14.70 alongside Seti at 20.26.

Thanks Conan.
____________

*Bump*

With all these nice changes going on recently the credits issue seems to have gone down a bit on the priority list... *grin*

Really, you have all a project could wish for: great forums, neat applications for different OSes (even 64-bit is supported)... if only the credits weren't so low!
My dual core lappy runs under XP 64-bit and usually I'm getting around 30-40 credits/hour on most of the projects. Some are around 25-30 cr/h but here I'm getting under 15cr/h!

Please, can you do something about it? *fluttering my eyelashes* :-)))
____________
Bribe me with Lasagna!! :-)

*Bump*

With all these nice changes going on recently the credits issue seems to have gone down a bit on the priority list... *grin*

Really, you have all a project could wish for: great forums, neat applications for different OSes (even 64-bit is supported)... if only the credits weren't so low!
My dual core lappy runs under XP 64-bit and usually I'm getting around 30-40 credits/hour on most of the projects. Some are around 25-30 cr/h but here I'm getting under 15cr/h!

Please, can you do something about it? *fluttering my eyelashes* :-)))

Have to add that such concerns of low credit has been mentioned with our team.
An issue that should be addressed soon would be appreciated. Since other projects are awarding more credits for less cpu time. For me it is not an issue, but for serious crunchers... that is their game one could say.
Heidi-Ann Kennedy
____________

Recognized by the Carnegie Institute of Science . Washington D.C.

Changing the credit method means that work done before the change is worth less credit then after the change. That is not fair to all that crunch now. You might want to consider that in your deliberations.

Frankly, I have no problem with the credit system now, I can see what others doing this project are doing. Why does it matter that places like MilkyWay give more credit then you. People that are credit obsessed tend to flock around the high payers, you can see it in there portfolio. I know what I think of them, but whatever floats your boat.
____________
Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.

Changing the credit method means that work done before the change is worth less credit then after the change. That is not fair to all that crunch now. You might want to consider that in your deliberations.

Frankly, I have no problem with the credit system now, I can see what others doing this project are doing. Why does it matter that places like MilkyWay give more credit then you. People that are credit obsessed tend to flock around the high payers, you can see it in there portfolio. I know what I think of them, but whatever floats your boat.

SETI@home changes their credits all the time. And they are supposed to be the freakin' benchmark. And all the projects are supposed to be matching SETI, which means all the projects have to constantly re-adjust too. *sigh*
____________
Dublin, CA
Team SETI.USA

I don't understand why there has to be this big difference between my 'puters with different OS when I compare them up against the formula "claimed credit" = ((Whetstone + Dhrystone) x Cpu Seconds)/1728000??

I don't understand why there has to be this big difference between my 'puters with different OS when I compare them up against the formula "claimed credit" = ((Whetstone + Dhrystone) x Cpu Seconds)/1728000??

Because Docking uses
credit = CPU seconds * (19 * Whetstone + Dhrystone) / 12,096,000

That's the reason it claims so low on most machines, because the floating point benchmark score is usually a lot lower than the integer one. Granting 1000 credits a week instead of 100 credits a day for the virtual 1000 MFlops and 1000 MIPs standard computer does not help as real ones have normally a Whetstone benchmark factor 2 higher than the Dhrystone value.


@ the project staff:
By the way, using benchmark based credits without quorum is really brain-damaged if you are concerned about the malicious behaviour of some people (as it appears you are judging from some comments here), as it is one of the easiest things to manipulate those benchmark scores. Furthermore the whole BOINC integrated benchmark stuff is seriously flawed as it varies a lot between different OSs or BOINC versions. Furthermore it does not value architectural improvements of the CPUs and the ecosystem which don't improve the benchmark scores. Just as an example, for the exactly same WU, an AMD Phenom running XP64 gets about 88 credits, a Phenom with XP32 104 credits, an AthlonX2 running WinXP32 gets 114 credits and an Intel Core i7 (with Hyperthreading reducing the performance per individual thread) under XP32 gets even 124 credits for the exact same work. That does not look right to me! Awarding one system almost 50% higher credits for the same work because it is actually slower for the achieved benchmark score is really the wrong way to tackle the credit issue ;)

It isn't that hard to implement fixed credits as the WUs appear to be very even sized. It is the second best thing after flops based credits (i.e. really counting the executed operations in the code) and has the advantage that it could be implemented immediately.

This credit stuff is important to a lot of crunchers. So if you want to secure or even extend your user base, you should think about starting to credit at least on par to other projects. Look at Spinhenge for instance! They adopted a fixed credit scheme half a year ago and it works really well. With such a scheme in place there is no way to "cheat" to get more credits than others. Besides using more resources to crunch of course ;)

No feedback?

Maybe the project should have a look to the recent events at Aqua@home. Such things could happen here too as long as you don't fix your credits!

I don't want to demonstrate it as Alliance Francophone has done it there, but it is really easy to cheat here!

No feedback?

Maybe the project should have a look to the recent events at Aqua@home. Such things could happen here too as long as you don't fix your credits!

I don't want to demonstrate it as Alliance Francophone has done it there, but it is really easy to cheat here!

Maybe the project should have a look to the recent events at Aqua@home. Such things could happen here too as long as you don't fix your credits!

I don't want to demonstrate it as Alliance Francophone has done it there, but it is really easy to cheat here!

We understand that credits are important for some of our volunteers. Still the issue of the credits is an open issue. We had, for a short time, a fixed amount of credits per result but then some of our volunteers felt that they were penalized because they had slow machines.

If you feel that D@H does not reward you for your commitment, please feel free to donate your idle cycles to other projects.

We are currently double-testing the new screensaver. One of our D@H volunteers identified a problem in the visualization and we have been able to fix the issue. Now we want to make sure that the code works properly before to distribute it. I want to point out how the issue with the visualization was found by one of you and this is just great because we feel that you all are part of our team.

Just a small addon.

We feel that any demonstration against a single project not only damages the work of students dedicated to their research but also (and more importantly) damages the other volunteers participating in the project and in general the volunteer computing paradigm.

Total Credit 0
Avg. credit 0.00
CPU type AuthenticAMD
AMD Athlon(tm) MP 1500+ [Family 6 Model 6 Stepping 2]
Number of CPUs 2
Operating System Linux
2.4.20-64GB-SMP
Memory 1008.22 MB
Cache 256 KB
Swap space 5122.25 MB
Total disk space 114.5 GB
Free Disk Space 21.65 GB
Measured floating point speed 1000000 million ops/sec
Measured integer speed 1000000 million ops/sec

.

We are currently double-testing the new screensaver. One of our D@H volunteers identified a problem in the visualization and we have been able to fix the issue. Now we want to make sure that the code works properly before to distribute it. I want to point out how the issue with the visualization was found by one of you and this is just great because we feel that you all are part of our team.

Once we have the new screensaver out, we will have a meeting to discuss the credit issue. Again, it is very challenging to meet all the expectations but once again we will do our best.

Thank you for your support!

Michela

I just want to clarify that I'm not this guy . He/she/it had obviously less ojections than me against a small demonstration. Just look at this task

Task ID 6386453
Name 1yqj_mod0014p38alpha_28381_449956_2
Workunit 5860272
Created 11 Jul 2009 18:32:21 UTC
Sent 11 Jul 2009 18:41:12 UTC
Received 12 Jul 2009 5:40:07 UTC
Server state Over
Outcome Success
Client state Done
Exit status 0 (0x0)
Computer ID 38017
Report deadline 22 Jul 2009 6:01:12 UTC
CPU time 29938.21
stderr out <core_client_version>6.6.23</core_client_version>
<![CDATA[
<stderr_txt>
Calling BOINC init.
Starting charmm run (initial or from checkpoint)...
Calling BOINC init.
Starting charmm run (initial or from checkpoint)...
SUCCESS - Charmm exited with code 0.
Resolving file charmm.out...
Calling BOINC finish.
called boinc_finish

</stderr_txt>
]]>

Validate state Valid
Claimed credit 210249.324966669
Granted credit 210249.324966669
application version 6.15

You've got a point, Gipsel ;)

.

We are currently double-testing the new screensaver. One of our D@H volunteers identified a problem in the visualization and we have been able to fix the issue. Now we want to make sure that the code works properly before to distribute it. I want to point out how the issue with the visualization was found by one of you and this is just great because we feel that you all are part of our team.

Once we have the new screensaver out, we will have a meeting to discuss the credit issue. Again, it is very challenging to meet all the expectations but once again we will do our best.

Thank you for your support!

Michela

Whoohooo...

The Brain-Power of: University of Delaware, The Scripps Research Institute,and the University of California - Berkeley creates a new Screenserver!

Thats great!

iwanthimiwanthimiwanthim....

MB ;-)

You've got a point, Gipsel ;)

So what is happening now?
I see the project has deleted that _[Docker]_ account and some posts referring to it, too. Good, but are you doing something to solve the problem at its root?

Double post.

So what is happening now?
I see the project has deleted that _[Docker]_ account and some posts referring to it, too. Good, but what are you doing to solve the problem at its root?

Geht doch.. Dark Gipsel...

http://docking.cis.udel.edu/community/forum/thread.php?id=447

Geht doch.. Dark Gipsel...

The mess created by Alliance Francophone over at Aqua is quite bad in my opinion.

The mess created by Alliance Francophone over at Aqua is quite bad in my opinion.

It's not the mess created by ALL the Alliance...
First it was only two of them, second it was created in order to show that there was a very big problem with the points, don't forget this please.
But everybody prefer scream about them instead of screaming on all the cheaters which were doing their BIG credits silently......

This is pathetic.... somebody is upset about the amount of credit so they take to hacking results.... Childish!!! :wall:

Docking is not about credit for crunching...... it's about the science.

If this hacking with credit continues then I will probably say goodbye to Docking.

This is pathetic.... somebody is upset about the amount of credit so they take to hacking results.... Childish!!! :wall:

Docking is not about credit for crunching...... it's about the science.

If this hacking with credit continues then I will probably say goodbye to Docking.

I'd vote for fixed, server based credit. The BOINC benchmarking system is useless, as it unreasonably favors certain processors and OSes. It also encourages various cheats and hacks. Server based credits preclude most of the problems and will make your lives (and ours) much more peaceful.

I'd vote for fixed, server based credit. The BOINC benchmarking system is useless, as it unreasonably favors certain processors and OSes. It also encourages various cheats and hacks. Server based credits preclude most of the problems and will make your lives (and ours) much more peaceful.

What are the pros of variable credits? Three reasons why fix credits will not always be the right way to assign credits in Docking@Home

1. We hare running simulations with different proteins and ligands: each complex has a different size in terms of number of atoms and this can result in variable lengths for the jobs when moving from one complex to another.

2. We are running different docking models: two algorithms are used for the docking simulations, each with different characteristics and lengths in terms of flops and time. Model 13 is shorter than model 14 because it uses a different representation of the solvent.

3. Last and most important, each job has a non-deterministic lengths (the non-determinism is intrinsic in the molecular dynamics simulation performed): we set up a certain number of random conformations per job for our ligand and for each conformation we set up a certain number of rotations, however, if during the docking simulation there is an energy violation, the simulation is terminated. The volunteer gets the credits for the computer work done to that point and no penalty is applied. The volunteer can just proceed with the simulation of the next job. We use the simulation results before the violation happens - nothing is wasted! We cannot predict in advance the energy violation but it is better to stop the jobs that are causing the violation rather than continuing them.

If the third condition happens, the assignment of fix credits is not fair. However, the client starts immediately to crunch a new job and to get new credits.


How are we now preventing volunteers to get 1M credits per job? We changed the validation daemons so that we do not assign credits if:

1. suddenly a client asks higher amount of credits than in the past
2. clients ask more than expected for similar machines. In other words, each job can get a maximum amount of credits.

If any of the conditions above happens the jobs is classified as invalid.


What is our next step? We will put a survey open for the next 20 days to collect your votes and set up the credit system accordantly.

Docking is not about credit for crunching...... it's about the science.

If this hacking with credit continues then I will probably say goodbye to Docking.

I know y'all are more experienced at this than I, but I"m wondering if there's a server-side way of determining from the uplaoded results how many cycles were carried out in the particular work unit? It totally makes sense that they're not deterministic and you can't know exactly how long or how much math each one will required, but in the final analysis when you have the data back, are there ways to figure out how many computations were used to generate the returned results? (refinement cycles * atoms * model 13 or 14 correction * credit/flop) or something like that? My thought then is that a failed work unit might still actually generate some credit since the machine expended effort on that. I had a lot of failed work units at some point that went on for hours without terminiating, or dropped after a few hours, but processor time was used and the RAC dropped a lot (takes almost a month to recover). This would also be harder to mess with. You'd be able to use some similar metrics about time to completion vs. similar systems, if more cycles are reported than can be reasonably done in the time the unit ran, etc. Just a thought,
Tony

If you had access to the source-code and could implement a counter or something like that, this would be possible with no problem (to at least check how much work was done in a asymptotic manner).

BUT: the problem seems to be, that docking runs a wrapper around a wrapper (around a wrapper?) as the CHARMM model, program and force-field must be licensed in order to use it and no changes to the source-code are allowed for third parties.

What are the pros of variable credits? Three reasons why fix credits will not always be the right way to assign credits in Docking@Home

1. We hare running simulations with different proteins and ligands: each complex has a different size in terms of number of atoms and this can result in variable lengths for the jobs when moving from one complex to another.

2. We are running different docking models: two algorithms are used for the docking simulations, each with different characteristics and lengths in terms of flops and time. Model 13 is shorter than model 14 because it uses a different representation of the solvent.

3. Last and most important, each job has a non-deterministic lengths (the non-determinism is intrinsic in the molecular dynamics simulation performed): we set up a certain number of random conformations per job for our ligand and for each conformation we set up a certain number of rotations, however, if during the docking simulation there is an energy violation, the simulation is terminated. The volunteer gets the credits for the computer work done to that point and no penalty is applied. The volunteer can just proceed with the simulation of the next job. We use the simulation results before the violation happens - nothing is wasted! We cannot predict in advance the energy violation but it is better to stop the jobs that are causing the violation rather than continuing them.

How are we now preventing volunteers to get 1M credits per job? We changed the validation daemons so that we do not assign credits if:

1. suddenly a client asks higher amount of credits than in the past
2. clients ask more than expected for similar machines. In other words, each job can get a maximum amount of credits.

If any of the conditions above happens the jobs is classified as invalid.

Measured floating point speed 747.84 million ops/sec
Measured integer speed 1382.91 million ops/sec

Measured floating point speed 1335.22 million ops/sec
Measured integer speed 2249.84 million ops/sec

If you had access to the source-code and could implement a counter or something like that, this would be possible with no problem (to at least check how much work was done in a asymptotic manner).

BUT: the problem seems to be, that docking runs a wrapper around a wrapper (around a wrapper?) as the CHARMM model, program and force-field must be licensed in order to use it and no changes to the source-code are allowed for third parties.

Applaud your approach to help resolve.
I myself have found your explanation informative and on the mark.
I would highly suggest you (docking admin) maintain this discussion with him since it is done intelligently. Would also suggest that someone from your team try to contact via e-mail and work in a more cooperative manor.

On the boards is not promoting a positive image for the project!

But both parties must be willing not to just present and debate, but listen and consider.
Heidi-Ann Kennedy
____________

Recognized by the Carnegie Institute of Science . Washington D.C.

[i]Generally there are a lot of problems with the BOINC benchmarks even if one does not manipulate them. The benchmark values vary a lot when comparing different BOINC versions and/or a different OS. As an example look at this computer running Client 5.10.45 under Linux and this completely identical machine just with WinXP. The Linux hosts registers benchmark values of only[quote]Measured floating point speed 747.84 million ops/sec
Measured integer speed 1382.91 million ops/sec

while under Windows I see

Measured floating point speed 1335.22 million ops/sec
Measured integer speed 2249.84 million ops/sec

Quite a difference I think.

Furthermore there are sometimes severe problems with CPUs capable of dynamically changing their clockspeed. That are virtually all Notebook CPUs. But you may know that AMD CPUs downclock itself under light load to 800MHz or 1GHz, while under full load they may run at more than 3GHz. I've seen several systems where the benchmark caused too less load to "wake up" the CPU to the full clockspeed, whereas the WUs run at full throttle afterwards. This leads to severly underclaiming hosts and if the benchmark values get (correctly) recalculated at some point (there is a random componont to this problem) they would get their WUs marked as invalid (because of claiming much more than before) with your proposed system. Another problem is that there may be heavy (non-BOINC) activity on the system when the Benchmark is executed. This will also lead to severly reduced scores.

But also overclaiming benchmarks are entirely possible without willfully manipulating something. Just think of the new Core i7 series and its "Turbo" feature. If only one core is loaded and/or the CPU temperature is low it raises the frequency of the loaded core(s). This leads easily to benchmark scores (which partly runs only single threaded!) not representative of the actual crunching speed. The hyperthreading feature makes this even worse actually. I think I gave already that example of 88 credits claimed by a Phenom or Core2 and 124 credits claimed by a Core i7 for the same WU. And this problem will continue to get more pronounced as the CPU manufactures will implement further features helping the crunching speed but not the benchmark score or increase the functionality of such automated load and temperature dependend clocking schemes for CPUs like Cool&Quiet, SpeedStep or that Turbo feature.

All in all, even if the benchmark could not be manipulated, it still lacks the property to represent the crunching power of a system. So why on earth do you want to base the credits on it?
With the provisions you have taken you try the repair a concept that is literally fubar. Maybe you should ask yourself why most projects (especially the bigger ones) use fixed credits. The simple answer is that it is probably the easiest and safest way.

What is our next step? We will put a survey open for the next 20 days to collect your votes and set up the credit system accordantly.

What is our next step? We will put a survey open for the next 20 days to collect your votes and set up the credit system accordantly.

Has the survey been posted?

I'm also for server assigned credits. Something is definitately up with the current system. I just went through some of my workunits and found that different computers are getting different amounts of credit for the same work. My laptop cranks out a workunit in about the same time as my workstation (similar speed cores, the workstation just has more of them). They complete a similarly sized workunit in about the same time, but the laptop is receiving 1/4 the credit of the workstation. Very weird.

They complete a similarly sized workunit in about the same time, but the laptop is receiving 1/4 the credit of the workstation. Very weird.

They complete a similarly sized workunit in about the same time, but the laptop is receiving 1/4 the credit of the workstation. Very weird.

That is the problem with the changing clockspeed during the benchmark I spoke of. One of the reasons why benchmark based credits are simply crap.

Server based credit all the way :-)
The BOINC benchmark system is worthless.

Server based credit all the way :-)
The BOINC benchmark system is worthless.

Could the admin please delete this host, and remove entire credit of the user.

36565

Obviously this is someone that cares nothing about the science and only about generating credit.


GenuineIntel
Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz [x86 Family 6 Model 15 Stepping 11]
Number of CPUs 4
Operating System Microsoft Windows Server 2003
Standard Server x86 Edition, Service Pack 2, (05.02.3790.00)
Memory 2038.06 MB
Cache 244.14 KB
Measured floating point speed 8648.2 million ops/sec
Measured integer speed 18731.66 million ops/sec


And

36563

GenuineIntel
Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz [x86 Family 6 Model 15 Stepping 11]
Number of CPUs 4
Operating System Microsoft Windows Server 2003
Standard Server x86 Edition, Service Pack 2, (05.02.3790.00)
Memory 2037.38 MB
Cache 244.14 KB
Measured floating point speed 6490.6 million ops/sec
Measured integer speed 8604.28 million ops/sec

Pretest a new batch of WUs. Set a fixed amount of credits for it.

Even if there are a few WUs, that might finish earlier (or last longer?): All in all, it will be just as fair as possible.

Cosmology also had fixed credits (was it 50 per WU?) with varying wu length, but every user has the chance to get a shorter wu for the same amount of credits - instead of a few cheaters taking advantage of this crappy benchmark based credit system...

Best regards!
____________


My NEW BOINC-Site

Why people joined BOINC Synergy...

Same for Einstein, within one science run the time needed to complete one unit is differing up to 30%.
Over some more work units it averages out for everyone...

server side credits + 1

Duplicate post, kindly remove it ;-)

+1 from me for fixed credits.

btw: anyone accounted for the +39 votes from phoenix rising "for server-side credits" from this thread / post? http://docking.cis.udel.edu/community/forum/thread.php?id=448&nowrap=true#5197

fixed credits please!

+ 1 from me.

I think, the onliest possibility to solve the credit problem is fixed credit

fixed Credits rock!:P

fixed credits +1

greets

elite.bl4ze

I think, the onliest possibility to solve the credit problem is fixed credit

+1 from me for fixed credits.

Please fixed Credits for me! 64-Bit-Version would be nice

Greets

+1 from me for fixed credits.

My vote for fixed credits!

My vote for fixed credits!

my vote for fixed

vote for fixed credits!

Yes, we can. <- is like the choice between plague and cholera.

Fixed credits is the way!

I see just -[Docker]- has 88 credits for a WU get ... Whether that's politically correct? The good new Germany is 88 for /:=) and prohibited! Allow me a joke.

Thank you for attention.

+1 from me for fixed credits.

Please fixed Credits for me! 64-Bit-Version would be nice

Greets

Fixed Credits is the only chance for D@H to avoid cheating.

In fact, all WU running the same time (+-10%). Set fixed credits for this and no Docker-Account made trouble...

[X]fixed Credits

+1 for fixed credits please!

We are testing D@H with fix credits.

Michela

____________
If you are interested in working on Docking@Home in a great group at UDel, contact me at 'taufer at acm dot org'!

Hi, quite NEW and the first post.

Benchmark only, without taking time into account, simply sucks.

Most of the WU's I've seen, have within a few %, the same amount of data to be crunched. But this can change, ofcoarse.
Fixed credits, IMHO, will give less trouble, compaired to a FLOP's and time based
method.
But I'm still NOT convinced, what is the most reasonable and
fair method in credit approval!
Does Docking use a quorum based checking and/or validating?
What other methods are or have being used?
And I have some reading to do. ;)

[x] fixed credits

We are testing D@H with fix credits.

Michela

Fixed Credits - will make my Day. Signed!

(Thanks Gipsel for the Heads up ;-) )

[x] fixed Credits.
You crunch an WU and know, what you get for it. Simple and clear. And noone will be upset, that his old computer gets less Credit, that is rasy to understand

[x] fixed credits, of course!

No one is wondering that a new 300 hp-car is faster than an old 50 hp-car... why should that be different with computers?


off topic:
ok, in the (most?) US-States there is a speedlimit ;) come to Germany and try it without speedlimit :) it's fun!
I thought, there is a US-State without a speedlimit, but I couldn't find one. I'm just prying: Is there one?

[x] fixed credits, of course!

No one is wondering that a new 300 hp-car is faster than an old 50 hp-car... why should that be different with computers?


off topic:
ok, in the (most?) US-States there is a speedlimit ;) come to Germany and try it without speedlimit :) it's fun!
I thought, there is a US-State without a speedlimit, but I couldn't find one. I'm just prying: Is there one?

I have been sitting back quietly crunching for Docking@home for many months. I am not one of the big heavy weights who crunch only for cobbles. I only have four quad core systems dedicated to Docking plus a few part time crunchers. After reading this thread for the third time ... it has been going on for over a year now ... several things are pretty obvious.

a. We all know that fixed credits reduce cheating in projects where batches can be adequately benchmarked.

b. We all know that docking@home credits are below industry average.

c. We all know that nothing has changed in over a year. Plenty of talk, little action.

I just reviewed a the completed work on my machines and indeed, it appears that batches are fairly consistent. The active batch is 48 cobbles. Shortly before that was an 83 cobble batch. It seems that you should have a pretty good idea how much processing a work unit should take. Fixed credits with "flag for inspection" on anyone who claims something outside the range of reasonable seems to me to be a no-brainer. If a flagged work unit comes out higher than benchmark, then reward the contributor. If not, and you see a pattern, ban them.

Finally, credits are low. You know that. I know that. Everyone knows that. The exact multiplier to conform to industry standard is somewhere near 1.5x what you are granting. You can no longer use SETI as the "gold standard" because the CUDA client is not separated, but the numbers posted over the years show a pretty clear pattern.

In summary, I am contributing to docking@home because I think it is doing good work. But, the dc nut in me feels slighted by the below average credits. The claim that you can not adjust credits to a level more consistent with the rest of the field out of fear of attracting too many cheaters does little to satisfy, especially when it seems clear that you are doing batches of fixed size units.

Anybody saw fixed credits yet?

Cheers!
____________


My NEW BOINC-Site

Why people joined BOINC Synergy...

We are testing fixed credits in a mirrored system. We expect to have everything ready in the next couple of days.

We are testing fixed credits in a mirrored system. We expect to have everything ready in the next couple of days.

Thanx for the info!
____________


My NEW BOINC-Site

Why people joined BOINC Synergy...

Delighted to hear that we will soon be getting fixed credits. It is the only way to go.
____________
Proud member of BOINC@AUSTRALIA

It took more than 2 days, because of the non-deterministic nature of our tasks, but we are ready to move to fixed credits tomorrow, after we finish the distribution of 1k1i-trypsin-model14

We'll keep you posted

Fixed credits are used now. We will keep tunning the flops constant in the following weeks. Your input will be greatly appreciated

Fixed credits are used now. We will keep tunning the flops constant in the following weeks. Your input will be greatly appreciated

Haven't been around much lately... and now what do my tiny little eyes see?
FIXED credits!

Thank you, thank you, thank you! That's what I've been waiting for a long time!
____________
Bribe me with Lasagna!! :-)

Fixed credits are used now. We will keep tunning the flops constant in the following weeks. Your input will be greatly appreciated

Fixed credits are great, really. Very much appreciated.

I always had the impression, that something similar was already installed, as my computer always claimed less (and got granted the same amount) as the benchmarks would have claimed, 21 C/h claim compared to 25 C/h according to benchmarks. I thought that my machine was not so well suited to this algorithm as others, and thus got less than claims based on Flop-count or whatever.

Now I claim still the same (where do these claims come from anyway?), but get more than double my benches granted. This looks like I'm exorbitantly well suited for the current algorithm (or better my puter is).

55 C/h is at the top end of credit granting projects for CPU on my machine, far more than average. As there are no wingmen, I can't compare directly with other machines how my performance is and why I get so much more then usual.
____________
Gruesse vom Saenger

For questions about Boinc look in the BOINC-Wiki

Hello everybody,

It's great to hear that you are pleased!! Hopefully we won't have many of those nasty workunits that take more than 13 hrs (or the story will be different)


Hi Saenger,

Claimed credits came from the benchmarks (still) but now claims are ignored and the assigned credit comes from the server (by calculating how much a workunit from a given type -protein-ligand-model- is worth). Most of the people is getting more than what they are claiming (because we remember that everybody was complaining that our project was 1.5X behind the average of the BOINC projects). I assume that in some weeks most of the machines will stabilize with the new system and then it will start making sense to compare performance again

Claimed credits came from the benchmarks (still)

Claimed credits came from the benchmarks (still)

My Computer has benches as follows:
Measured floating point speed 3239.93 million ops/sec
Measured integer speed 8951.05 million ops/sec

claimed credit = ([whetstone]+[dhrystone]) * wu_cpu_time_in_sec / 1728000

For my machine per hour: (3239,93 + 8951,05) * 3600 / 1728000 = 25,397875

My claims here are very consistent at 21 credits per hour since a very long time. [..]
So I'm definitely not claiming according to my benchmarks.

Sure you do. Look here for an explanation! How it all started ;)

Sure you do. Look here for an explanation! How it all started ;)

How did you know this formula?

is it stated anywhere?

Is there any explanation for using a non-standard formula?

I understand to leave benchmarks and move to flop-count or fixed credits, but altering the orginal formula makes absolutely no sense to me if the buggy benches are still used.

You are completely right. But that's beating a dead horse as we have fixed credits now.

Fixed credits are used now. We will keep tunning the flops constant in the following weeks. Your input will be greatly appreciated