I've reviewed quite a few quorums to which my machines have returned results from the calibrated client.
On SETI, I agree that my returns tended to be skewed a bit higher than the main distribution--though it was not higher by anywhere near the degree to which use of the stock client made them lower. So if fitting the main distribution was the criterion, it was much better than the stock client, but skewed high.
Here in Einstein, the same rough and ready observation seems to find me rather in the center of the distribution. I've seen some cases where a dozen results in a row would find the quorum awarding my claim--meaning the calibrating client's conclusion was the center of the three on offer. Overall I was downclaimed about as often as upclaimed, usually by fairly small margins. Uniformly, when downclaimed by a large margin (say a factor of three), a review of the quorum has shown that all three of us were akosf users, and that the other two reported running the stock client. So far these have been somewhat uncommon--but increasing.
It gets knocked off calibration center for a while by disturbing events. For example once a week when my Windows 98 SE machines run a Norton virus scan the faulty CPU time reporting in Win 98 means that the active result is reported as taking about 25% longer than usual. While trux filters extreme outliers, this is within the filter limit and knocks the calibration toward under claiming, with a recovery with the same dynamics as the original calibration.
My overall answer to your question is that it is doing far better than the available alternatives I know about, most particularly vastly better than use of the stock client.
Caveat--I don't know how Boinc Studio compares in this regard. There is an extensive thread on that topic on this forum which you may like to review.
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.
No guarantees possible. If one is using Trux (and BoincStudio?) they could turn calibration off for the other projects. But human nature is the deciding factor on that issue. As for myself, I use Crunch3r. I'm happy with it and will probably continue to use it instead of another tweaked client. Calibration cannot be turned off with C3r. And I'm guilty of crunching for QMC occasionally. Mainly got back on it for a filler project because I don't know for sure if there is going to be a crunching lapse between the S4 and S5 runs.
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?
Only if 100% of the participants use the optimized clients. Not going to happen (see my first post). I agree that the solution lies with BOINC (and perhaps the projects) that a more equal system is worked out. But that has yet to be hashed out and the hashing has been going on for a long time. People just can't see eye to eye for some reason...
I crunch for my team and admit to being somewhat competitive. But mainly I'm with my team for the fun and team website and like being associated with an excellent bunch of people. I'm with Einstein 'cause I want to be a part of the science. Others have no team and don't care about the credits so much. If they want to crunch just for the science, they've got my sincere respect. They have to pay the electric bill too regardless. All the arm twisting, shaming, and bullying is not going to change any minds. Quite the opposite for me. If people start dropping out because they are dissatisfied with the project it's not going to affect Einstein in the long run. The project has already accelerated forward due to the optimized apps and will continue with more people finding out about the apps everyday. Approx. 224 new registered users (2,190 boxes) in the past 24 hrs. and like numbers everyday. And when the "official" apps come thru then I believe the processing will take off like a rocket.
It is great that Mike Hewson will "cobble" together a thread outlining all the options available. Then everyone (who happen to read the forums) can be well informed on the various options of the Betas and Asko's apps and optimized clients and can decide on what is right for them with the computer(s) they paid for.
-edit- I see 4 people posted while I was putting this post together. Also thanx DarkStar, after reading your post I'll make a reassessment of Crunch3r and Truxoft. You clarified the "differences" quite nicely.
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.
Sorry, I am not catching what you mean? It is a proven fact, that text conversations are always much more open to interpretation than vocal or face-to-face. This is due to missing tone of voice or body language. With your background from SETI forums, you assume that this message has the same tendency, which is your interpretation.
I used "please" and raised awareness for the importance of my message by capitalising those words I found essential. I also find it important that when collaborating you should adhere to a common rule base and I wanted to make clear that people brake these rules when just using optimised alberts but no BOINC calibration. There is nothing to be discussed about - period. Catch my drift? Admittedly, from the follow up conversation, I do understand that there is something to be discussed. According to the definitions when using optimised apps you must claim less, but doing so cheats others - a total contradiction in ethics here.
Well, I don't mind if a forum moderator takes up the call and puts this thought into an officially matching statement. In fact I very much support the idea, because it reiterates the importance for equality to all participants one should pay intention to.
:
your thoughts - the ways :: the knowledge - your space
:
(...) or adopt the CPDN method and grant set credits for each lenght WU.
Doesn't really sound like a bad idea. Also, I do understand your point about the validity of claiming only 1/4 of credits when using optimised versions. The problem however is that people have different apps, so some claim and deserve more, than those that use optimised stuff.
Quite frankly, I give up! This credit system that we have right now does not work fairly for the community. Some use optimised apps that morally speaking have to claim less, but simultaneously they mess up those people who use the official stuff. This credit system will remain flawed for as long as there are not solely offical apps and clients in place.
What to do? I don't know. Maybe I should just start living with this credit system being just a pile of pants. What good are the statistics, team ranking and the like if we just as well might role the dice?
:
your thoughts - the ways :: the knowledge - your space
:
And don't try to goad me into feeling guilty about it since I'm in no way culpable for this credit system.
If you had taken the time to read my post properly, you would have seen that I'm not trying to make you feel guilty. I'm (along with countless others) just telling you that you are wrong. You claim that "I contend that it is not my responsibility to fiddle with calibrating clients or any other gimmick relating to credits" yet by using an optimised app, yet sticking to the official BOINC client, you are doing just that. Fiddling with the credits.
Quote:
I do not consider donating to a project of my choice as rubbish. You have your reasons for participating and I have mine.
Please explain to me where exactly in the sentence "Before anyone starts the old "It's about the science, not the credit" rubbish, just remember this." I have said that participating in this, or any other project, is rubbish. What is rubbish is the argument of "It's about the science, not credits". Both the science and credits are of equal importance. Whist I agree that credits are of no material value, they are our reward for our participation in a project and some are not getting their full reward due to people only doing half the job of optimising their system.
Quote:
Look at it this way, you are doing approximately 4 times the work of someone using the non optimised app, but still getting the same credit. True but not my fault.
So who's fault is it that you won't install the calibrating client then?
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.
Actually, the time factor itself has been one of the larger bones of contention in regard to the credit systems in general, not only in regard to calibrating/optimized clients and applications. One alternative viewpoint goes something like:
Thus, if a computer completes 4x as many WUs as another computer, then OF COURSE it should claim 4x the credit. It's simple math.
A slightly different version, but with essentially the same result, is:
Thus, if the same amount of work is accomplished by two different computers, then OF COURSE those two computers should claim the same credit. It's simple math.
Of course, if it's really "all about the science", then either of those would seem to make a certain amount of sense in logical terms, as "the science" is advanced by the amount of work accomplished, regardless of clock time. Should a project be sensitive to turnaround times (LHC comes to mind) where the "science" actually derives benefit from a more rapid return of results, it might even be appropriate for the credit system for that particular project to grant "bonus" credit for faster turnaround - the computer processing 4x results per period of time gets 4x+1 credit or some such.
Actually, though, I think all of this is outside the scope of the thread, so my apologies to others in advance for running down this particular bunny trail.
What are credits really worth? I tried cashing them in for a pizza, and a drink and the guy just laughed at me :)
The discovery of a gravitational wave event would be priceless. The lack of discovery would tells us something equally important.
Progress in either regard will only be achieved if the data gets crunched. The faster it gets crunched, the better. So Akosf's executables serve a valuable role. That's why I run them. I have a dual boot machine with Linux and Windows, but I run Einstein@home almost exclusively on Windows with Akosf's exectubles.
I was a little miffed that optimized executables were not available for Linux, but then came the pizza shop episode (metaphorically) and I realized that the best I could do to help the project was to not get hung up on my OS preference and crunch fast with whatever means I had available. When I am not using Linux for my daily computing needs, I reboot the machine to Windows to run E@H.
I was a little miffed that optimized executables were not available for Linux, but then came the pizza shop episode (metaphorically) and I realized that the best I could do to help the project was to not get hung up on my OS preference and crunch fast with whatever means I had available. When I am not using Linux for my daily computing needs, I reboot the machine to Windows to run E@H.
I am running E@H 24/7 on a 400 MHz Pentium II with SuSE Linux. Often my results are still pending because more powerful CPUs, even 2 Pentium 4, running Windows have not completed their WUs. I too have a dual boot system with WIN98SE but I use WIN98 only to fly with Microsoft Flight Simulator.
Tullio
OK, munchers & crunchers, try this for a draft:
[draft]
Unofficial Advisory
There has been rapid progress in significant optimisations of some of the science applications for E@H. These versions can accelerate the processing of work units many fold. This is a good thing, but has entailed an unexpected effect.
The user of a faster version may also be using:
#1. The standard BOINC client. This will result in substantially lower credit claim per work unit.
OR
#2. A calibrated BOINC client. This will, after time, result in much the same credit claim per work unit as before.
OR
#3. An optimised BOINC client. Please see this post for an explanation of the behaviour of optimised vs calibrated BOINC clients, and why the use of an optimised BOINC client is deprecated.
There are instances where some quora are formed with users who are using the optimised science application versions alongside users who use the standard science application versions. If the users of the former are using the standard BOINC client then the lower credit hence claimed may swing the awarded claim downwards for the entire quorum - and specifically for the latter who have the standard science version and standard BOINC client.
Many Einstein@Home forum participants have thus concluded that, on balance, the use of a calibrated client ( most likely Trux's ) when the faster science applications are used, is fairest to all.
The reasons for doing this may be found here. It contains much discussion and comment from active forum participants.
There are always troubles when we come to damn credits on all project...perhaps not on CPDN :-)
Using trux client might be fine for a calibration, not a solution for "Curse of 32". One can't serve all the parties, heh? It might be consdered unfair for those willing to help in larger portin (i.e. run-as-fast-as-my-machine-can).
So, using BS core and it's (ThierryH's) calibration may be a better choise.
Anyway, after we all get dry soon...in 4 weeks let's say:
1a. E&H needs a newer application. Perhaps with some built-in optimalizations of akosf's ideas and them of use in large scale? I'm sure this will help whole project more than coupled machines running extra-optimalized apps (and faking CPU numbers).
1b. Having says that, this may somehow solve the problem of non-Windows platforms and their users. It may be considered very unfair to crunch 5x and even more time per WU while source code is not available.
2. Is there a plan for implementing FLOPs counting, which will leave the troube of #1, #2 and #3 options irrelevant?
I'm not saying leave it as it is now, but bringing larger picture that seeks for general, not partial/temporary solution.
RE: Questions on using
)
I've reviewed quite a few quorums to which my machines have returned results from the calibrated client.
On SETI, I agree that my returns tended to be skewed a bit higher than the main distribution--though it was not higher by anywhere near the degree to which use of the stock client made them lower. So if fitting the main distribution was the criterion, it was much better than the stock client, but skewed high.
Here in Einstein, the same rough and ready observation seems to find me rather in the center of the distribution. I've seen some cases where a dozen results in a row would find the quorum awarding my claim--meaning the calibrating client's conclusion was the center of the three on offer. Overall I was downclaimed about as often as upclaimed, usually by fairly small margins. Uniformly, when downclaimed by a large margin (say a factor of three), a review of the quorum has shown that all three of us were akosf users, and that the other two reported running the stock client. So far these have been somewhat uncommon--but increasing.
It gets knocked off calibration center for a while by disturbing events. For example once a week when my Windows 98 SE machines run a Norton virus scan the faulty CPU time reporting in Win 98 means that the active result is reported as taking about 25% longer than usual. While trux filters extreme outliers, this is within the filter limit and knocks the calibration toward under claiming, with a recovery with the same dynamics as the original calibration.
My overall answer to your question is that it is doing far better than the available alternatives I know about, most particularly vastly better than use of the stock client.
Caveat--I don't know how Boinc Studio compares in this regard. There is an extensive thread on that topic on this forum which you may like to review.
RE: Can you also guarantee
)
No guarantees possible. If one is using Trux (and BoincStudio?) they could turn calibration off for the other projects. But human nature is the deciding factor on that issue. As for myself, I use Crunch3r. I'm happy with it and will probably continue to use it instead of another tweaked client. Calibration cannot be turned off with C3r. And I'm guilty of crunching for QMC occasionally. Mainly got back on it for a filler project because I don't know for sure if there is going to be a crunching lapse between the S4 and S5 runs.
Only if 100% of the participants use the optimized clients. Not going to happen (see my first post). I agree that the solution lies with BOINC (and perhaps the projects) that a more equal system is worked out. But that has yet to be hashed out and the hashing has been going on for a long time. People just can't see eye to eye for some reason...
I crunch for my team and admit to being somewhat competitive. But mainly I'm with my team for the fun and team website and like being associated with an excellent bunch of people. I'm with Einstein 'cause I want to be a part of the science. Others have no team and don't care about the credits so much. If they want to crunch just for the science, they've got my sincere respect. They have to pay the electric bill too regardless. All the arm twisting, shaming, and bullying is not going to change any minds. Quite the opposite for me. If people start dropping out because they are dissatisfied with the project it's not going to affect Einstein in the long run. The project has already accelerated forward due to the optimized apps and will continue with more people finding out about the apps everyday. Approx. 224 new registered users (2,190 boxes) in the past 24 hrs. and like numbers everyday. And when the "official" apps come thru then I believe the processing will take off like a rocket.
It is great that Mike Hewson will "cobble" together a thread outlining all the options available. Then everyone (who happen to read the forums) can be well informed on the various options of the Betas and Asko's apps and optimized clients and can decide on what is right for them with the computer(s) they paid for.
-edit- I see 4 people posted while I was putting this post together. Also thanx DarkStar, after reading your post I'll make a reassessment of Crunch3r and Truxoft. You clarified the "differences" quite nicely.
RE: Then I'd like the
)
Sorry, I am not catching what you mean? It is a proven fact, that text conversations are always much more open to interpretation than vocal or face-to-face. This is due to missing tone of voice or body language. With your background from SETI forums, you assume that this message has the same tendency, which is your interpretation.
I used "please" and raised awareness for the importance of my message by capitalising those words I found essential. I also find it important that when collaborating you should adhere to a common rule base and I wanted to make clear that people brake these rules when just using optimised alberts but no BOINC calibration. There is nothing to be discussed about - period. Catch my drift? Admittedly, from the follow up conversation, I do understand that there is something to be discussed. According to the definitions when using optimised apps you must claim less, but doing so cheats others - a total contradiction in ethics here.
Well, I don't mind if a forum moderator takes up the call and puts this thought into an officially matching statement. In fact I very much support the idea, because it reiterates the importance for equality to all participants one should pay intention to.
:
your thoughts - the ways :: the knowledge - your space
:
RE: (...) or adopt the CPDN
)
Doesn't really sound like a bad idea. Also, I do understand your point about the validity of claiming only 1/4 of credits when using optimised versions. The problem however is that people have different apps, so some claim and deserve more, than those that use optimised stuff.
Quite frankly, I give up! This credit system that we have right now does not work fairly for the community. Some use optimised apps that morally speaking have to claim less, but simultaneously they mess up those people who use the official stuff. This credit system will remain flawed for as long as there are not solely offical apps and clients in place.
What to do? I don't know. Maybe I should just start living with this credit system being just a pile of pants. What good are the statistics, team ranking and the like if we just as well might role the dice?
:
your thoughts - the ways :: the knowledge - your space
:
RE: And don't try to goad
)
If you had taken the time to read my post properly, you would have seen that I'm not trying to make you feel guilty. I'm (along with countless others) just telling you that you are wrong. You claim that "I contend that it is not my responsibility to fiddle with calibrating clients or any other gimmick relating to credits" yet by using an optimised app, yet sticking to the official BOINC client, you are doing just that. Fiddling with the credits.
Please explain to me where exactly in the sentence "Before anyone starts the old "It's about the science, not the credit" rubbish, just remember this." I have said that participating in this, or any other project, is rubbish. What is rubbish is the argument of "It's about the science, not credits". Both the science and credits are of equal importance. Whist I agree that credits are of no material value, they are our reward for our participation in a project and some are not getting their full reward due to people only doing half the job of optimising their system.
So who's fault is it that you won't install the calibrating client then?
RE: Thus if a computer
)
Actually, the time factor itself has been one of the larger bones of contention in regard to the credit systems in general, not only in regard to calibrating/optimized clients and applications. One alternative viewpoint goes something like:
Thus, if a computer completes 4x as many WUs as another computer, then OF COURSE it should claim 4x the credit. It's simple math.
A slightly different version, but with essentially the same result, is:
Thus, if the same amount of work is accomplished by two different computers, then OF COURSE those two computers should claim the same credit. It's simple math.
Of course, if it's really "all about the science", then either of those would seem to make a certain amount of sense in logical terms, as "the science" is advanced by the amount of work accomplished, regardless of clock time. Should a project be sensitive to turnaround times (LHC comes to mind) where the "science" actually derives benefit from a more rapid return of results, it might even be appropriate for the credit system for that particular project to grant "bonus" credit for faster turnaround - the computer processing 4x results per period of time gets 4x+1 credit or some such.
Actually, though, I think all of this is outside the scope of the thread, so my apologies to others in advance for running down this particular bunny trail.
.
What are credits really
)
What are credits really worth? I tried cashing them in for a pizza, and a drink and the guy just laughed at me :)
The discovery of a gravitational wave event would be priceless. The lack of discovery would tells us something equally important.
Progress in either regard will only be achieved if the data gets crunched. The faster it gets crunched, the better. So Akosf's executables serve a valuable role. That's why I run them. I have a dual boot machine with Linux and Windows, but I run Einstein@home almost exclusively on Windows with Akosf's exectubles.
I was a little miffed that optimized executables were not available for Linux, but then came the pizza shop episode (metaphorically) and I realized that the best I could do to help the project was to not get hung up on my OS preference and crunch fast with whatever means I had available. When I am not using Linux for my daily computing needs, I reboot the machine to Windows to run E@H.
RE: I was a little miffed
)
I am running E@H 24/7 on a 400 MHz Pentium II with SuSE Linux. Often my results are still pending because more powerful CPUs, even 2 Pentium 4, running Windows have not completed their WUs. I too have a dual boot system with WIN98SE but I use WIN98 only to fly with Microsoft Flight Simulator.
Tullio
OK, munchers & crunchers, try
)
OK, munchers & crunchers, try this for a draft:
[draft]
Unofficial Advisory
There has been rapid progress in significant optimisations of some of the science applications for E@H. These versions can accelerate the processing of work units many fold. This is a good thing, but has entailed an unexpected effect.
The user of a faster version may also be using:
#1. The standard BOINC client. This will result in substantially lower credit claim per work unit.
OR
#2. A calibrated BOINC client. This will, after time, result in much the same credit claim per work unit as before.
OR
#3. An optimised BOINC client. Please see this post for an explanation of the behaviour of optimised vs calibrated BOINC clients, and why the use of an optimised BOINC client is deprecated.
There are instances where some quora are formed with users who are using the optimised science application versions alongside users who use the standard science application versions. If the users of the former are using the standard BOINC client then the lower credit hence claimed may swing the awarded claim downwards for the entire quorum - and specifically for the latter who have the standard science version and standard BOINC client.
Many Einstein@Home forum participants have thus concluded that, on balance, the use of a calibrated client ( most likely Trux's ) when the faster science applications are used, is fairest to all.
The reasons for doing this may be found here. It contains much discussion and comment from active forum participants.
Installation instructions for TruXoft:
[draft]
Comments please - wording, errors, tone, BBcode, whatever
..... flame-trousers on .... :-)
Cheers, Mike.
( edit ) Whoops, I meant flameproof-trousers ....
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
Thanks for the draft,
)
Thanks for the draft, Mike.
There are always troubles when we come to damn credits on all project...perhaps not on CPDN :-)
Using trux client might be fine for a calibration, not a solution for "Curse of 32". One can't serve all the parties, heh? It might be consdered unfair for those willing to help in larger portin (i.e. run-as-fast-as-my-machine-can).
So, using BS core and it's (ThierryH's) calibration may be a better choise.
Anyway, after we all get dry soon...in 4 weeks let's say:
1a. E&H needs a newer application. Perhaps with some built-in optimalizations of akosf's ideas and them of use in large scale? I'm sure this will help whole project more than coupled machines running extra-optimalized apps (and faking CPU numbers).
1b. Having says that, this may somehow solve the problem of non-Windows platforms and their users. It may be considered very unfair to crunch 5x and even more time per WU while source code is not available.
2. Is there a plan for implementing FLOPs counting, which will leave the troube of #1, #2 and #3 options irrelevant?
I'm not saying leave it as it is now, but bringing larger picture that seeks for general, not partial/temporary solution.