Agreed. Then I'd like the moderator to "unsticky" this one. The opening post uses a tone that reminds me of the personal animus which has consumed too much recent discussion on the SETI forums lately.
We had a pretty good optimized clients thread going for a while--if the point is to invite people to review the discussion and reasoning the proposed entry could point to that.
In the spirit of the spendid brevity of the optimized ap thread, perhaps there could be an entry along these lines:
************************
Use of an optimized science ap with the standard BOINC client will lead to very low credit claim per work unit. This may subtract credit from others who happen to share a quorum with one of your results. Many Einstein@Home forum participents have concluded that on balance use of an optimized client--most likely Trux's Calibrating Client--is fairest to all.
A discussion of reasons for doing this and initial behavior may be found here. The specific post pointed to is a general overview, and the thread in which it appears contains much discussion and comment from active forum participants.
Installation instructions are here.
*********************
Okay, I failed to meet our moderator's (or akos') brevity standards, but this was just a trial text. I did not put a link in for installation instructions, as the one's on Trux's site are a bit skimpy, and to my taste the ones in the BOINC wiki are so conservative as to raise the pain threshold too high. If someone knows of a set of instructions written to the right level of detail (for example in the admirable style of Richard Haselgrove) please mention it.
To our moderator: Should you like this idea, please feel free to use as much or as little of my suggestion as you like, including pointing to different references.
Capital ideas! I'm rather flat chat right now, and I've just woken up to all this ( UTC + 10 ), and don't we all love Fridays, but I'll massage something up in the next 24 - 36 hours. It is definitiely a sufficiently important issue to not let run away on us in SETI style. Meantime please keep those suggestions ( especially wording etc ) coming!! :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
The reason simply is that the already badly flawed credit system is now completely for the drain altogether. Instead of the average 45 Credits, one fifth of my credits now look like: http://einsteinathome.org/workunit/8137449
I don't want to go through my WU list and abort those units where people cheat me, because I do not want to cheat the Einstein team! Yet this is now becoming wide scale antisocial behaviour and therefore frustrating. I give those people the benefit of the doubt, that they don't know about this fact, but if you participate in this project you should play by the rules. PERIOD.
So what are Mac users supposed to do? Detach their hosts, as penance for having been dragging you down all along with their "cheating"?
So what are Mac users supposed to do? Detach their hosts, as penance for having been dragging you down all along with their "cheating"?
I'd sure hope Mac users stick with the project. This is just about a measure some folks can take to keep the scoring system more even-handed.
Every time two of the three members of a quorum are either stock/stock or akosf ap plus calibrated client, all is well. Urging more akosf ap users to calibrate is just a matter of keeping the odds high for that two out of three.
And no, I don't think you or I are cheating at all, each just getting as much science out of our machine and our power consumption as we can.
This thread is growing very rapidly, so I hope nobody has already written this small idea:
All of you who are using optimized Akos' applications really should use also optimized clients, even in the case you are not much into the credit.
The reason is simple - not all user are interested only in science. If users with official applications get less credit because of the other using optimized ones, they might consider quitting the project!
Thus, using an optimized applications without optimized clients can harm the project! Please, consider this, and those of you informing on your local websites about optimized applications, inform also about this danger to the project and inevitability of using the opt. clients.
UCB and the projects should provide a proper credit system to assuage the masses who care about it. I wish I could offer a way to make it happen.
SETI have tried that with (so called) Enhanced and, to be honest, they have made a complete balls up of it. Not only do you get less credit per hour than using the non optimised version of the old science app, you are actually doing MORE WORK per hour. People are up in arms over this and there are some very heated discussions over on their forum. And where is it written that participants are entitled to a particular amount of credit per hour or WU or any other measurement that you can perceive? Seems to me that most people want as much credit as they can get because they engage in a perceived competition and always are looking for an advantage. But what really matters is that everyone is treated equally and equitably so that fair comparisons can be made amongst what you, I and others contribute. And that is not my responsibility. OTH, I joined distributed computing solely to offer as much processing to the project(s) of my choice as my single computer can, and for that reason I installed the Akos app where I can achieve a four-fold increase in throughput.
At the moment, regardless of wether you are using the official app or one of the optimised apps, your computer is still doing the same work, it's just doing it faster. A look at your results shows that you are claiming on average approx 14 credits per workunit, My avreage is approx 45, it will also be about 45 credits for everyone else using the calibrating client. And you want to solicit me instead of UCB/UWM to help you get what you think you deserve.
Look at it this way, you are doing approximatly 4 times the work of someone using the non optimised app, but still getting the same credit. True but not my fault. Would you do 4 times the work at your place of employment for the same money you get now? I'm not earning a living by donating unused cpu cycles to a worthy cause, hence the term "donate" --not expecting anything in return.
It also works the other way, some poor sod with one old PC that takes best part of a day to complete 1 workunit is, rightly, expecting his 45-50 credits. Trouble is, his PC is in the same quorum as your computer, and someone else with the optimised app, but still bog standard BOINC client and instead of getting his 50 credits, he gets 14. How fed up is he going to feel? I'm sure he is depressed because the credit system is not equitable (and should be fixed). Linux hosts aren't happy either because of the low benchmarking and because Akos benefited the windows/pentium crowd.
Before anyone starts the old "It's about the science, not the credit" rubbish, just remember this. I do not consider donating to a project of my choice as rubbish. You have your reasons for participating and I have mine.
SETI classic introduced Credits, Teams, Tables etc. to bring a bit of competition into the project and to increase the amount of work done for them. If it was not for the credits, most people probably would not have participated as SETI played on the competitive instincts that everyone has. Agreed. And UCB/UWM should make every effort to make that system of competitive spirit as fair as possible. Yet I contend that it is not my responsibility to fiddle with calibrating clients or any other gimmick relating to credits. I understand how/why the current credit awards are inequitable and why people are exasperated --I'm quite sympathetic-- but the solution lies with UCB/UWM not me. And don't try to goad me into feeling guilty about it since I'm in no way culpable for this credit system.
When used here does it calibrate accurately?
On Seti the calibration was done to a wrongly percieve notion that the credits/unit should average at 32.nn. This was brought about by refering it to a reference unit, that actually takes 20 to 30 per cent longer to crunch than an average unit. I asked Trux about this and he was rather evasive in his answer, but my observation on Seti was that a lot of computers using it were over-claiming.
Can you also guarantee that user of the optimised client will only use it on projects that have optimised applications?
Use of optimised clients on other projects are causing concern because of high claims. At Rosseta for example because the validation is done with the science, and not compared to the output of others, the granted is the same as the claimed.
When the S4 project finishes in a few weeks, we will hopefully move to the S5 project and the application for this will already have been optimised. Will use of the optimised client then claim correctly?
First, those are two different things. There are optimizing clients, and there are calibrating clients. They operate differently, and the difference is key.
Optimizing clients operate by attempting to adjust benchmarks, which is an across-the-board increase - those are the source of most of the "unfairly high claimed credit" complaints, as they generally work across the board on all projects, rather than just those where there is an optimized science application in use.
Calibrating clients (trux's) operate in a slightly different manner, by adjusting the actual processing time and adjusting it to a reported time that more closely reflects results that would have been achieved with an unoptimized science application. It also allows turning calibration on or off on a "by project" basis. The interesting thing about this option is that it's necessary to keep the calibration off on projects to where there's not an optimized science application in place to keep from *reducing* the amount of credit claimed. Yes, you read that right - in most cases when using the calibrating client with a release (non-optimized) science application, the calibration will actually adjust downward - if not immediately, then over time. That's one reason why it has a built-in "negative calibration" limit. So, complaints about overhigh credit claims on projects without an optimized science application are, in general, groundless where the calibrating clients are concerned.
Quote:
When used here does it calibrate accurately?
It appears to, if used with one of akosf's optimized science applications.
Quote:
On Seti the calibration was done to a wrongly percieve notion that the credits/unit should average at 32.nn. This was brought about by refering it to a reference unit, that actually takes 20 to 30 per cent longer to crunch than an average unit. I asked Trux about this and he was rather evasive in his answer, but my observation on Seti was that a lot of computers using it were over-claiming.
That may have been the case with his earlier "optimized" clients that were subsequently deprecated in favor of the "calibrating" clients. As someone who processed a significant number of SETI work units with the calibrating client, I feel comfortable in saying that it's calibrated claims were generally appropriate, claiming near the middle or perhaps slightly above - in any case, usually neither the highest nor the lowest of the three claims.
Quote:
Can you also guarantee that user of the optimised client will only use it on projects that have optimised applications? Use of optimised clients on other projects are causing concern because of high claims. At Rosseta for example because the validation is done with the science, and not compared to the output of others, the granted is the same as the claimed.
Nobody can guarantee anything, but anyone using a calibrating (as opposed to optimized - see previous) client on a project without an optimized science application will usually end up with reduced, rather than inflated, average credit claims. Optimized clients, however, are another story, and I would agree with you are generally "bad form" at best.
Quote:
When the S4 project finishes in a few weeks, we will hopefully move to the S5 project and the application for this will already have been optimised. Will use of the optimised client then claim correctly?
Actually, if it follows the form of the SETI_Enhanced debacle, where the release client is supposedly optimized, and credit is granted by FpOps, use of either won't matter. If not, I suppose we'll just need to wait and see - certainly no need to throw the baby out before the bath water is even drawn!
Not that credit is particularly important anyway - it's really all about the science, isn't it?
For the record, I use Akosf's app and Trux's client just to get away from being called a cheat.
BUT
According to the wiki. Credit is calculated from the system benchmarks and the amount of time taken to complete the WU.
Thus if a computer completes a WU in 1/4 of the time taken to complete it by another computer, then OF COURSE it should claim 1/4 the credit. It's simple math.
Is this fair to the "slower" machine, probably not. but that is not the fault of the science app NOR is it the fault of the client, it is mearly the system used to calculate credit.
Untill a bullet proof calculation method comes along then the use of CC's and the like are the only way that I can see to redress the inadequacy of the current system.
Either that or adopt the CPDN method and grant set credits for each lenght WU.
First a couple observations, and then why I haven't used such CCs before (though how this would all fall, I would have to look further, and couldn't really ask on the respective boards as certain user bases are up in arms on RAC cheating, over-claimed credits, and are even suggesting that perhaps the projects should start banning all non-official clients/anyone caught using them):
- In principle, the fpop idea that we see on SETI doesn't seem bad, and in principle I think it can be really good means to get outa this whole claimed credit dilema.
- However, in practice an upward shift on their entire credit system (aka granting/claiming slightly higher credits per run time might be in order). On an observational basis, I noticed that a 4.18 WU using the 4.11 crunch3r app, has about the same credit claim as a 5.12 enhanced WU does using the newer crunch3r. Time wise, crunch3r enhanced does help (2 hours 10 mins on my A64, vs. I was seeing like 16 hours when I got the enhanced in SETI beta, and other users are reporting way more then 2 hour crunch times).
However, for the same credit, 4.11 crunch3r was getting the work done in 45 minutes, vs. 2 hours 10 minutes (at least at the .8 AR which my WUs on 5.12 came in on), but claiming the same credit for more then 2x crunch time.
Yes, I did see a negative hit. It's not to say this couldn't be adjusted, if the under-claiming credit, could be upshifted by a slight increase in the constant (if this is how they're working it) that the fpops are multiplied by, to get the actual credit. Then each fpop would be made worth a slight bit more, from a credit standpoint...
- Yes I use akosf's optimized app, and a standard client. And it is true, I prefer when the other people crunching my WU are using the standard client :rofl Well, I guess we can all see where this goes :D
- However, I can also say that Einstein and SETI are only 2 projects I run, and most projects (well CPDN based projects don't matter, as they give a fixed credit per trickle regardless) don't have an optimized app. In particular, Rosseta, RALPH, and QMC would be of concern, and all 3 I crunch for. They don't run a quorum on credits, granting claimed; and it would be too easy to cheat there, which is what has much of the user bases on those projects up in arms. Up in arms enough, to even be suggesting that anyone seen using a non-standard client gets "auto-banned" from their projects...
- Note the suggesting of bannings for using optimized/calibrating clients. Even the suggestion of getting hit with punative actions, even if one were making and can make a good faith effort to keep everything fair, is umm :eek:
- As it is, even Einstein and SETI combined, get a small percentage of resource share here. Other projects without an optimized app, claim most of the crunching time.
At least if one can disable (on a per project basis), it does take a bit of the negative sting away (minus possibilities of getting punative action because of what others have/can/or can't avoid doing with such clients). Hmm...
RE: Agreed. Then I'd like
)
Capital ideas! I'm rather flat chat right now, and I've just woken up to all this ( UTC + 10 ), and don't we all love Fridays, but I'll massage something up in the next 24 - 36 hours. It is definitiely a sufficiently important issue to not let run away on us in SETI style. Meantime please keep those suggestions ( especially wording etc ) coming!! :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
I read you, and I'm
)
I read you, and I'm flattered. But it's just gone midnight here in the UK, and my style is flagging....
I use Trux's CC, so I should be able to knock something up if you like - give me a day or two, I spent too long on the SETI boards today.
RE: Everybody using
)
So what are Mac users supposed to do? Detach their hosts, as penance for having been dragging you down all along with their "cheating"?
RE: So what are Mac users
)
I'd sure hope Mac users stick with the project. This is just about a measure some folks can take to keep the scoring system more even-handed.
Every time two of the three members of a quorum are either stock/stock or akosf ap plus calibrated client, all is well. Urging more akosf ap users to calibrate is just a matter of keeping the odds high for that two out of three.
And no, I don't think you or I are cheating at all, each just getting as much science out of our machine and our power consumption as we can.
This thread is growing very
)
This thread is growing very rapidly, so I hope nobody has already written this small idea:
All of you who are using optimized Akos' applications really should use also optimized clients, even in the case you are not much into the credit.
The reason is simple - not all user are interested only in science. If users with official applications get less credit because of the other using optimized ones, they might consider quitting the project!
Thus, using an optimized applications without optimized clients can harm the project! Please, consider this, and those of you informing on your local websites about optimized applications, inform also about this danger to the project and inevitability of using the opt. clients.
RE: RE: UCB and the
)
Questions on using
)
Questions on using calibrating optimised client.
When used here does it calibrate accurately?
On Seti the calibration was done to a wrongly percieve notion that the credits/unit should average at 32.nn. This was brought about by refering it to a reference unit, that actually takes 20 to 30 per cent longer to crunch than an average unit. I asked Trux about this and he was rather evasive in his answer, but my observation on Seti was that a lot of computers using it were over-claiming.
Can you also guarantee that user of the optimised client will only use it on projects that have optimised applications?
Use of optimised clients on other projects are causing concern because of high claims. At Rosseta for example because the validation is done with the science, and not compared to the output of others, the granted is the same as the claimed.
When the S4 project finishes in a few weeks, we will hopefully move to the S5 project and the application for this will already have been optimised. Will use of the optimised client then claim correctly?
Andy
RE: Questions on using
)
First, those are two different things. There are optimizing clients, and there are calibrating clients. They operate differently, and the difference is key.
Optimizing clients operate by attempting to adjust benchmarks, which is an across-the-board increase - those are the source of most of the "unfairly high claimed credit" complaints, as they generally work across the board on all projects, rather than just those where there is an optimized science application in use.
Calibrating clients (trux's) operate in a slightly different manner, by adjusting the actual processing time and adjusting it to a reported time that more closely reflects results that would have been achieved with an unoptimized science application. It also allows turning calibration on or off on a "by project" basis. The interesting thing about this option is that it's necessary to keep the calibration off on projects to where there's not an optimized science application in place to keep from *reducing* the amount of credit claimed. Yes, you read that right - in most cases when using the calibrating client with a release (non-optimized) science application, the calibration will actually adjust downward - if not immediately, then over time. That's one reason why it has a built-in "negative calibration" limit. So, complaints about overhigh credit claims on projects without an optimized science application are, in general, groundless where the calibrating clients are concerned.
It appears to, if used with one of akosf's optimized science applications.
That may have been the case with his earlier "optimized" clients that were subsequently deprecated in favor of the "calibrating" clients. As someone who processed a significant number of SETI work units with the calibrating client, I feel comfortable in saying that it's calibrated claims were generally appropriate, claiming near the middle or perhaps slightly above - in any case, usually neither the highest nor the lowest of the three claims.
Nobody can guarantee anything, but anyone using a calibrating (as opposed to optimized - see previous) client on a project without an optimized science application will usually end up with reduced, rather than inflated, average credit claims. Optimized clients, however, are another story, and I would agree with you are generally "bad form" at best.
Actually, if it follows the form of the SETI_Enhanced debacle, where the release client is supposedly optimized, and credit is granted by FpOps, use of either won't matter. If not, I suppose we'll just need to wait and see - certainly no need to throw the baby out before the bath water is even drawn!
Not that credit is particularly important anyway - it's really all about the science, isn't it?
.
Same old argument, Just new
)
Same old argument, Just new names.
For the record, I use Akosf's app and Trux's client just to get away from being called a cheat.
BUT
According to the wiki. Credit is calculated from the system benchmarks and the amount of time taken to complete the WU.
Thus if a computer completes a WU in 1/4 of the time taken to complete it by another computer, then OF COURSE it should claim 1/4 the credit. It's simple math.
Is this fair to the "slower" machine, probably not. but that is not the fault of the science app NOR is it the fault of the client, it is mearly the system used to calculate credit.
Untill a bullet proof calculation method comes along then the use of CC's and the like are the only way that I can see to redress the inadequacy of the current system.
Either that or adopt the CPDN method and grant set credits for each lenght WU.
First a couple observations,
)
First a couple observations, and then why I haven't used such CCs before (though how this would all fall, I would have to look further, and couldn't really ask on the respective boards as certain user bases are up in arms on RAC cheating, over-claimed credits, and are even suggesting that perhaps the projects should start banning all non-official clients/anyone caught using them):
- In principle, the fpop idea that we see on SETI doesn't seem bad, and in principle I think it can be really good means to get outa this whole claimed credit dilema.
- However, in practice an upward shift on their entire credit system (aka granting/claiming slightly higher credits per run time might be in order). On an observational basis, I noticed that a 4.18 WU using the 4.11 crunch3r app, has about the same credit claim as a 5.12 enhanced WU does using the newer crunch3r. Time wise, crunch3r enhanced does help (2 hours 10 mins on my A64, vs. I was seeing like 16 hours when I got the enhanced in SETI beta, and other users are reporting way more then 2 hour crunch times).
However, for the same credit, 4.11 crunch3r was getting the work done in 45 minutes, vs. 2 hours 10 minutes (at least at the .8 AR which my WUs on 5.12 came in on), but claiming the same credit for more then 2x crunch time.
Yes, I did see a negative hit. It's not to say this couldn't be adjusted, if the under-claiming credit, could be upshifted by a slight increase in the constant (if this is how they're working it) that the fpops are multiplied by, to get the actual credit. Then each fpop would be made worth a slight bit more, from a credit standpoint...
- Yes I use akosf's optimized app, and a standard client. And it is true, I prefer when the other people crunching my WU are using the standard client :rofl Well, I guess we can all see where this goes :D
- However, I can also say that Einstein and SETI are only 2 projects I run, and most projects (well CPDN based projects don't matter, as they give a fixed credit per trickle regardless) don't have an optimized app. In particular, Rosseta, RALPH, and QMC would be of concern, and all 3 I crunch for. They don't run a quorum on credits, granting claimed; and it would be too easy to cheat there, which is what has much of the user bases on those projects up in arms. Up in arms enough, to even be suggesting that anyone seen using a non-standard client gets "auto-banned" from their projects...
- Note the suggesting of bannings for using optimized/calibrating clients. Even the suggestion of getting hit with punative actions, even if one were making and can make a good faith effort to keep everything fair, is umm :eek:
- As it is, even Einstein and SETI combined, get a small percentage of resource share here. Other projects without an optimized app, claim most of the crunching time.
At least if one can disable (on a per project basis), it does take a bit of the negative sting away (minus possibilities of getting punative action because of what others have/can/or can't avoid doing with such clients). Hmm...