Advanced search

Forums : Wish list : Linux Claims Low Credit
Message board moderation

To post messages, you must log in.

AuthorMessage
Profile Jayargh
Volunteer moderator
Volunteer tester
Avatar

Send message
Joined: 25 Jun 07
Posts: 508
Credit: 2,282,158
RAC: 0
Message 559 - Posted: 29 Jun 2007, 2:00:16 UTC
Last modified: 29 Jun 2007, 2:12:20 UTC

I realise this is early in the game pre-alpha and all but wanted to make you aware that Linux clients appear to claim 1/3rd of windows claims thus having a significant impact on a 2 quorum low granted. I bring this up now because it may have a significant impact on future growth of the project knowing Boinc crunchers. Please take this under advisement.

If you do nothing else server side to correct the disparity then granting an avg.of 2 will correct 50% of the problem at least short term.

Thanks JR
ID: 559 · Report as offensive     Reply Quote
Profile Webmaster Yoda

Send message
Joined: 28 Jun 07
Posts: 21
Credit: 1,632,327
RAC: 0
Message 562 - Posted: 29 Jun 2007, 6:10:39 UTC - in response to Message 559.  

If you do nothing else server side to correct the disparity then granting an avg.of 2 will correct 50% of the problem at least short term.

Thanks JR

It will indeed fix some of the problem (I don't like getting my credit halved either). It could however create another problem.

There are computers that massively overclaim (whether deliberate or not). With averaging, if one computer claims 2 credits and the other 100, they would both get 51 credits when a fair claim might be 5 credits.

If there is no other way to arrive at fair granted credits, I support averaging, but something would need to be done about these massive claims.

Perhaps something like this:

If Highest > (x * Lowest) then Granted = Lowest
Else Granted = (Highest + Lowest) /2

Where x could be something like 3, given the current disparity between Windows and Linux...
ID: 562 · Report as offensive     Reply Quote
John McLeod VII
Volunteer tester
Avatar

Send message
Joined: 8 Jun 07
Posts: 28
Credit: 305,469
RAC: 0
Message 565 - Posted: 29 Jun 2007, 12:01:20 UTC

Moany (if not all) of the massive overclaims are deliberate attempts to gain credit that was not earned. Some are a bit misguided attempts to optomize the BOINC client instead of the project application to gain processing speed.

By far the best way to fix the problem is to have the project application count FLOPs or some proxy for FLOPs and use the BOINC client API for direct reporting of FLOPs. This usually requires control of the source for the application. A second approach is to grant fixed credit. Fixed credit works well if the run times are consistent. A third approach is to grant fixed credits for particular runs. Rosetta does this to good effect as each molecule has a consistent run time that is distinct from other molecules.


BOINC WIKI
ID: 565 · Report as offensive     Reply Quote
Profile [B^S] Acmefrog
Volunteer tester
Avatar

Send message
Joined: 8 Jun 07
Posts: 175
Credit: 446,074
RAC: 0
Message 566 - Posted: 29 Jun 2007, 12:28:18 UTC - in response to Message 565.  

Moany (if not all) of the massive overclaims are deliberate attempts to gain credit that was not earned. Some are a bit misguided attempts to optomize the BOINC client instead of the project application to gain processing speed.

By far the best way to fix the problem is to have the project application count FLOPs or some proxy for FLOPs and use the BOINC client API for direct reporting of FLOPs. This usually requires control of the source for the application. A second approach is to grant fixed credit. Fixed credit works well if the run times are consistent. A third approach is to grant fixed credits for particular runs. Rosetta does this to good effect as each molecule has a consistent run time that is distinct from other molecules.


I like it when Docking went to fixed credits. Sure the credit was on the high side but the WUs were consistant and it didn't matter if you had a fast or slow machine or a pc, mac or Windows or Linux. You also didn't have to worry about someone 'cheating'.

Anyway, that was my two cents and I probably will not ever speak on how to grant credit again since I have seen the same topic in just about every project.
ID: 566 · Report as offensive     Reply Quote
Profile Scott
Volunteer moderator
Project administrator
Project developer
Avatar

Send message
Joined: 1 Apr 07
Posts: 662
Credit: 13,742
RAC: 0
Message 569 - Posted: 29 Jun 2007, 13:42:14 UTC

I'd like to hear more opinions about credit. Who is in favor of fixed credits and who is not?
Scott Kruger
Project Administrator, Cosmology@Home
ID: 569 · Report as offensive     Reply Quote
Svenie25

Send message
Joined: 21 Jun 07
Posts: 68
Credit: 34,092
RAC: 0
Message 572 - Posted: 29 Jun 2007, 13:59:47 UTC
Last modified: 29 Jun 2007, 14:00:01 UTC

I peronally think, fixed credits are the better option. You got no problems with "cheater"clients or people, who are crying because of the difference between different os or cpu´s.
ID: 572 · Report as offensive     Reply Quote
Profile Webmaster Yoda

Send message
Joined: 28 Jun 07
Posts: 21
Credit: 1,632,327
RAC: 0
Message 574 - Posted: 29 Jun 2007, 14:25:25 UTC
Last modified: 29 Jun 2007, 14:30:07 UTC

I have a strong preference for projects that have fixed credits, or some method of granting credit independently of the BOINC benchmarks.

Apart from blatant cheating and mis-configured hosts, there is of course the disparity between Linux and Windows when relying on BOINC benchmarks. Fixed credit / Flops counting sorts that out too.

We end up with a level playing field, fair competition. The only way to get ahead in the competition (which many participants thrive on) is to do more work or do it more efficiently.
ID: 574 · Report as offensive     Reply Quote
Profile Jayargh
Volunteer moderator
Volunteer tester
Avatar

Send message
Joined: 25 Jun 07
Posts: 508
Credit: 2,282,158
RAC: 0
Message 576 - Posted: 29 Jun 2007, 15:47:33 UTC - in response to Message 562.  

If you do nothing else server side to correct the disparity then granting an avg.of 2 will correct 50% of the problem at least short term.

Thanks JR

It will indeed fix some of the problem (I don't like getting my credit halved either). It could however create another problem.

There are computers that massively overclaim (whether deliberate or not). With averaging, if one computer claims 2 credits and the other 100, they would both get 51 credits when a fair claim might be 5 credits.



This being true I have not seen any way off overclaimers here and their are plenty of B-P here(BoincPolice) to bring it to devs attn. I was trying to get a quick fix for the 1-2 credit claims of linux while windows claims 5-6.

Fixed credit is preferred if it is easy to implement and if you can verify that all units of a given type take x amount of time consistently. Consistency is the key word here....that is the ONLY negative to a fixed credit system I am aware of. The projects with the fewest credit complaints by the users are the fixed credit at server projects.
ID: 576 · Report as offensive     Reply Quote
Profile Saenger
Volunteer tester
Avatar

Send message
Joined: 22 May 07
Posts: 110
Credit: 282,157
RAC: 0
Message 578 - Posted: 29 Jun 2007, 15:56:54 UTC

If possible I'd prefer fixed credits, next best is imho flop count, original bench * time calculation is too easy to be manipulated.

What I saw was a big difference in the crunching tme of my WUs, some lasted only 6.5 min, some took 20 min, so they should be awarded with a different credit according to the effort. I don't know the algorithm and the predictability of the duration. If it's possible to know beforehand how long it will take, give it some fixed credit, if not use the flop count.

If the WUs will stay this short, and it's not to be determined beforehand whether it will be a long or a short one (like with the azimut angle in Seti) it will be fine imho to grant the average for all, it will sort it out over time. BUt if it's determinable beforehand, some will probably presort their WUs and discard the long ones to increase the Credit/h ratio.

Flop count and fixed credit will as well lead to a different credit/h ratio on machines with the same benchmark, as the application has to fit some OS/CPU combinations better than others, but that's just fine imho. So you see whether your puter is suited to this project or will be better used somewhere else.
Grüße vom Sänger
ID: 578 · Report as offensive     Reply Quote
rbpeake

Send message
Joined: 27 Jun 07
Posts: 118
Credit: 61,883
RAC: 0
Message 581 - Posted: 29 Jun 2007, 16:08:40 UTC

Fixed credits seem to work fine on projects like Folding@home, where the project team runs their own benchmarks first, and then assign credit on that consistent basis.
ID: 581 · Report as offensive     Reply Quote
Profile Scott
Volunteer moderator
Project administrator
Project developer
Avatar

Send message
Joined: 1 Apr 07
Posts: 662
Credit: 13,742
RAC: 0
Message 582 - Posted: 29 Jun 2007, 16:20:54 UTC

I've only seen one host that is making incredible credit claims. However, I still think that fixed credit might be a good idea. Competition between users and teams for credits is beneficial in many ways, but I do not want to have to deal with claims of unfair client optimization and cheating. I'd rather spend my (rather limited) time improving the project than dealing with credit complaints on the forums, and I'm sure you all agree.

I don't think that there is an issue with WUs having variable lengths. The run-times for WUs are fairly stable, and besides, WUs are randomly distributed to users, so any run-time differences would average out in the end.

I'm not sure I want to implement fixed credits at this very moment, but it might be coming soon if people don't bring to light some serious, legitimate issues.
Scott Kruger
Project Administrator, Cosmology@Home
ID: 582 · Report as offensive     Reply Quote
John McLeod VII
Volunteer tester
Avatar

Send message
Joined: 8 Jun 07
Posts: 28
Credit: 305,469
RAC: 0
Message 597 - Posted: 29 Jun 2007, 21:24:16 UTC

The only issue for deciding to implement fixed would be variable run times, and if run times are stable, then this is not an issue.

The alpha testers can deal with whatever, but you should implement the credit solution you decide on before going public.



BOINC WIKI
ID: 597 · Report as offensive     Reply Quote
Profile Saenger
Volunteer tester
Avatar

Send message
Joined: 22 May 07
Posts: 110
Credit: 282,157
RAC: 0
Message 598 - Posted: 29 Jun 2007, 21:34:47 UTC - in response to Message 597.  
Last modified: 29 Jun 2007, 21:35:01 UTC

The only issue for deciding to implement fixed would be variable run times, and if run times are stable, then this is not an issue.

The alpha testers can deal with whatever, but you should implement the credit solution you decide on before going public.

I subscribe to that.

With small WUs a runtime difference will imho be not as important, but with bigger ones you call for anger here from the crunchers if you grant the same for 1h and for 3h on the same machine.
Grüße vom Sänger
ID: 598 · Report as offensive     Reply Quote
Profile Scott
Volunteer moderator
Project administrator
Project developer
Avatar

Send message
Joined: 1 Apr 07
Posts: 662
Credit: 13,742
RAC: 0
Message 600 - Posted: 29 Jun 2007, 21:53:38 UTC - in response to Message 598.  

I subscribe to that.

With small WUs a runtime difference will imho be not as important, but with bigger ones you call for anger here from the crunchers if you grant the same for 1h and for 3h on the same machine.

Not saying that it will happen, but if it were to happen, it wouldn't really matter because everybody would be experiencing the same thing. Assuming a random distribution of WUs, long and short run-time WUs would be distributed to users more-or-less evenly to all users. Therefore, nobody would have a real advantage in the long run.

Anyway, it's a moot point since run-times shouldn't vary much at all (I would estimate less than 1%).
Scott Kruger
Project Administrator, Cosmology@Home
ID: 600 · Report as offensive     Reply Quote
rbpeake

Send message
Joined: 27 Jun 07
Posts: 118
Credit: 61,883
RAC: 0
Message 601 - Posted: 29 Jun 2007, 21:57:45 UTC - in response to Message 598.  

...I subscribe to that.

With small WUs a runtime difference will imho be not as important, but with bigger ones you call for anger here from the crunchers if you grant the same for 1h and for 3h on the same machine.


Credit should be assigned proportionally to the time taken to crunch the work unit using one standard reference machine. Thus, longer work units are assigned greater credit in direct proportion to the time they took to crunch on the standard reference machine.

And you would be surprised (or maybe not) how discussions about "fair" credit can lead to some really drawn out and heated discussions on the forums of other projects. So I agree, to save yourself a lot of future grief be sure the credit system is well tested and ultimately agreed upon here in the alpha phase before you "go public". ;)
ID: 601 · Report as offensive     Reply Quote
rbpeake

Send message
Joined: 27 Jun 07
Posts: 118
Credit: 61,883
RAC: 0
Message 602 - Posted: 29 Jun 2007, 22:00:30 UTC - in response to Message 600.  

...Not saying that it will happen, but if it were to happen, it wouldn't really matter because everybody would be experiencing the same thing. Assuming a random distribution of WUs, long and short run-time WUs would be distributed to users more-or-less evenly to all users. Therefore, nobody would have a real advantage in the long run.

Anyway, it's a moot point since run-times shouldn't vary much at all (I would estimate less than 1%).


1% is probably acceptable. I was thinking you were ultimately going to distribute work units over the life of the project of varying length.

More than 1% variation would imho lead to heated credit discussions. Best not to go down that path! ;)

ID: 602 · Report as offensive     Reply Quote
Profile Saenger
Volunteer tester
Avatar

Send message
Joined: 22 May 07
Posts: 110
Credit: 282,157
RAC: 0
Message 603 - Posted: 29 Jun 2007, 22:10:52 UTC - in response to Message 602.  

...Not saying that it will happen, but if it were to happen, it wouldn't really matter because everybody would be experiencing the same thing. Assuming a random distribution of WUs, long and short run-time WUs would be distributed to users more-or-less evenly to all users. Therefore, nobody would have a real advantage in the long run.

Anyway, it's a moot point since run-times shouldn't vary much at all (I would estimate less than 1%).


1% is probably acceptable. I was thinking you were ultimately going to distribute work units over the life of the project of varying length.

More than 1% variation would imho lead to heated credit discussions. Best not to go down that path! ;)

I think everything up to 10% will be fine, other projects are not that accurate as well.

I personly could live with even more if it's averaged over the time, but I'm a project addict, like most of us here ;)
Grüße vom Sänger
ID: 603 · Report as offensive     Reply Quote
Profile [AF>Futura Sciences>Linux] Thrr-Gilag
Volunteer tester
Avatar

Send message
Joined: 22 May 07
Posts: 32
Credit: 145,576
RAC: 0
Message 685 - Posted: 2 Jul 2007, 15:45:43 UTC - in response to Message 600.  

I subscribe to that.

With small WUs a runtime difference will imho be not as important, but with bigger ones you call for anger here from the crunchers if you grant the same for 1h and for 3h on the same machine.

Not saying that it will happen, but if it were to happen, it wouldn't really matter because everybody would be experiencing the same thing. Assuming a random distribution of WUs, long and short run-time WUs would be distributed to users more-or-less evenly to all users. Therefore, nobody would have a real advantage in the long run.

That's right only if there's nothing that can make the difference between long and short WU. If there is, some will abort the long one and the random distribution will not lead to a good distribution.

And then it would lead to ABC credit system that give 1000 credits for comlpeted long WU in order to complete all the WU.

So, I thinck you just have to try your credit system as we are in small community and volounter testers



------
Thrr-Gilag Kee'rr

L'Alliance Francophone
ID: 685 · Report as offensive     Reply Quote
Profile Saenger
Volunteer tester
Avatar

Send message
Joined: 22 May 07
Posts: 110
Credit: 282,157
RAC: 0
Message 708 - Posted: 2 Jul 2007, 21:11:51 UTC

My Linux machine gets a good boost from the new fixed credits system, I got more than double the credits as claimed.

I crunch with a 5.8.16, so the benchmarks are par with those from Windows, seems the WUs simply are better suited for Linux, for whatever reason.
Grüße vom Sänger
ID: 708 · Report as offensive     Reply Quote

Forums : Wish list : Linux Claims Low Credit