Coming in a bit late on the conversation, and not expressing a strong view. But, cross-project parity is a bluff.
I was recently crunching for SETI Main, using the optimised clients for my rigs. I am now crunching for Malaria with those machines, and the rest of my window box crunch here.
Making use of a fairly stable RAC as a, sort of cross-project parity, using the same hardware (but optimised in SETI and stock client in Malaria). My SETI crunching is almost 3 x more than my Malaria one.
Just shows cross-project equality of output is really kite flying.
When I reach my target total in Malaria I will shift them to crunch here.
The solution for you is easy. Run the stock app in Seti like the most of users. Then the credits becomes like in Malaria...:)
One thing to keep in mind about the Plan is that Eric came up with it a means for addressing some specific issues with SAH only intially, and merely speculated that it might be useful for other projects to use in the context of CPP. How it got perceived as being the holy grail for all credit issues is the stuff legends are made of. ;-)
Unfortunately, where it does what he wanted for the limited set of hosts which all have the same basic capabilities, it can be shown that it does not work for the entire set of all possible hosts on a given project, and therefore does not work for CPP either.
Could you elaborate, for those of us not as much into SETI and AstroPulse?
Quote:
After putting some considerable thought into it, at this point in the game, implementing something which doesn't address the root issue is most likely worse than doing nothing.
Remember, these are the end times... ;-) A "credit war" is on the horizon...
OK, lets look at how it works for SAH:
The MultiBeam apps have been instrumented so that they can get an approximation of the amount of work done executing a task. The value of the FLOPcounter is shown in the tasks' stderr file in the slot directory while its running and in the CDATA section of the report when it's finished and sent back to the project.
Actually the FLOPcount isn't updated in real time while the tasks execute, IIRC. Therefore you would not see it in the file itself until it's ready to upload. Sorry about that. ;-)
So, take any arbitrary MB task; I grabbed one from the current top host over there for this example:
Benchmarks:
Integer (I) = 8998.3 MIOS
Floating Point (F) = 3013.4 MFLOPS
Application: Optimized Windows port of Kan v8x
Task:
Runtime: 2212.391 Seconds
FLOPcounter: 15,285,115,602,584.209000
Now let's calculate what the work would be using BM-T:
Combined Operations = (8998.3E6 + 3013.4E6) * 2212.391 or
COP = 26,574,576,974,700
We immediately see that we have a problem. The instrumented count of FLOP's is less than what we would expect to see from BM-T, therefore if you plug the FLOPcounter value in to the Claimed Credit calculator, the host is going to underclaim, compared to straight BM-T.
The key point here to remember is that all BOINC scoring, no matter how you do it for any given project, must be referenced back to BM-T, by definition.
That's what the the so called 'Credit Multiplier' is all about, Although for SAH the one reported by the applications should be call the 'Equivalent FLOP Multiplier' (EFM). In this case the value is 2.85 so:
Simple, this is what the whole flapdoodle is all about. The task was run with an optimized application and not one which is compliant with the definition of the Cobblestone.
Technically this is a simplification here, but the full technical explanation is one of the 'red herrings' rolled out by the Credit Anarchists (when they simplify it) to justify everybody just 'doing their own thing'.
For this specific host the 'Credit Multiplier' should be:
15.38 / 25.21 = X / 2.85 so solving for X;
X = (2.85 * 15.38) / 25.21 = 1.73
The current version of the issue has two parts:
1.) That multiplier is 'unique' to every single host, and the median of all current active hosts does NOT accurately reflect it for all hosts, since not all hosts have the same basic capabilities.
2.) The second part is political. The actual granted credit for this task was 50.44, and the real problem goes right back to when they made the choice to allow third party apps to run on the project without giving full thought to the ramifications of what that would mean in the context of relying on BM-T as the basis for the scoring system.
Finally, WRT to what I interpreted what Eric wanted to use the EFM for. It was to compensate for the known non-linearities in the FLOP vs Angle Range curve which has always existed for SAH.
That is one reason why I am happy with server side credits. No worries about client or app user ¨adjusted credit¨, if you know what I mean.
LOL...
I agree, and since I am from Missouri...
I have far more confidence that here at EAH this has been better thought out, not only in terms of this project, but in terms of the effect of what they do here has on the BOINC context as a whole.
This is the reason that I believe that what was set for the basis to convert work to Cobblestones back when S5 started accurately represented what the by that time inflated value of the Cobblestone currently was.
Therefore, since reducing the basis raises questions just better left unasked, for completely unscientific reasons; Why should EAH break from that and make any corrections to the basis here just to comply with what SAH is doing, when the hypothesis for why they are doing it has been disproved?
Does this ring a bell for long time EAH Crunchers? ;-)
Alinator
The key pieces are:
1) Is the application open-source or not?
2) Is the optimized application returning valid scientific results?
If the answer to #1 is yes, then if #2 is also yes, then if he wants to keep it to himself, it breaks only the "spirit" of open-source, not the "letter" of it, so I'd think that if he kept it to himself in that instance, the project's actions are unfair and they caved to a bunch of complaining/jealousy.
If the answer to #1 is yes, but #2 is no, then clearly the app's usage needs to be discontinued and/or that project would need to go to a quorum of 2.
If the answer to #1 is no, then there's no further discussion. The app's usage should be forbidden and the project leadership should take measures to ensure that it doesn't happen again...whatever those measures may be.
Does this ring a bell for long time EAH Crunchers? ;-)
Alinator
The key pieces are:
1) Is the application open-source or not?
2) Is the optimized application returning valid scientific results?
If the answer to #1 is yes, then if #2 is also yes, then if he wants to keep it to himself, it breaks only the "spirit" of open-source, not the "letter" of it, so I'd think that if he kept it to himself in that instance, the project's actions are unfair and they caved to a bunch of complaining/jealousy.
If the answer to #1 is yes, but #2 is no, then clearly the app's usage needs to be discontinued and/or that project would need to go to a quorum of 2.
If the answer to #1 is no, then there's no further discussion. The app's usage should be forbidden and the project leadership should take measures to ensure that it doesn't happen again...whatever those measures may be.
I was about to write something on this, but then I changed my mind because I think that this should really best be discussed in the MW@H forum. It's an important matter, no question. I would recommend that anyone interested in this controversy uses the MW@H forum search function to look for the keywords "open source" to find previous statements of the project devs and scientists on this matter and discuss their reaction now....but not here, please do that in the MW@H forum where the key stakeholders in this question can read it :-).
but not here, please do that in the MW@H forum where the key stakeholders in this question can read it :-).
Understand, but to do so, I'd have to attach...which would blow my semi-sorta "street cred" of not being someone that chased credits...since they would probably be the top credit awarder now that Cosmology has tanked...
Not only that, but I suspect the discussion amongst parties already present there will be...borderline non-kid-friendly based on the histoire of the similar issue at SETI some years ago...
Does this ring a bell for long time EAH Crunchers? ;-)
Yup. Been there, done that. The open source app question was resolved a while ago here at E@H. Also 'optimised' clients have been made irrelevant. I agree with Bikeman, let's leave the specifics of that one for the MW@H boards! :-)
Cheers, Mike.
( edit ) The general lessons/rules/decisions drawn out at E@H back then are several, including but not limited to:
- credit and science bearing executables are defined by the central 'authority' of the project's management, or if not are made irrelevant.
- volunteer users are not the project's management.
- it is better to explicitly define the boundaries of roles in advance and not in retrospect.
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
RE: Coming in a bit late on
)
The solution for you is easy. Run the stock app in Seti like the most of users. Then the credits becomes like in Malaria...:)
(I'm an opti app user in SETI)
Best regards.
Logan.
BOINC FAQ Service (Ahora, también disponible en Español/Now available in Spanish)
[url=]http://einstein.phys.uw
)
[url=]http://einstein.phys.uwm.edu/forum_reply.php?thread=6815&post=87393#87393]Beamed[/url] in from the Credit Adjustment thread
OK, lets look at how it works for SAH:
The MultiBeam apps have been instrumented so that they can get an approximation of the amount of work done executing a task. The value of the FLOPcounter is shown in the tasks' stderr file in the slot directory while its running and in the CDATA section of the report when it's finished and sent back to the project.
Actually the FLOPcount isn't updated in real time while the tasks execute, IIRC. Therefore you would not see it in the file itself until it's ready to upload. Sorry about that. ;-)
So, take any arbitrary MB task; I grabbed one from the current top host over there for this example:
Benchmarks:
Integer (I) = 8998.3 MIOS
Floating Point (F) = 3013.4 MFLOPS
Application: Optimized Windows port of Kan v8x
Task:
Runtime: 2212.391 Seconds
FLOPcounter: 15,285,115,602,584.209000
Now let's calculate what the work would be using BM-T:
Combined Operations = (8998.3E6 + 3013.4E6) * 2212.391 or
COP = 26,574,576,974,700
We immediately see that we have a problem. The instrumented count of FLOP's is less than what we would expect to see from BM-T, therefore if you plug the FLOPcounter value in to the Claimed Credit calculator, the host is going to underclaim, compared to straight BM-T.
The key point here to remember is that all BOINC scoring, no matter how you do it for any given project, must be referenced back to BM-T, by definition.
That's what the the so called 'Credit Multiplier' is all about, Although for SAH the one reported by the applications should be call the 'Equivalent FLOP Multiplier' (EFM). In this case the value is 2.85 so:
Corrected FLOPcount (CF) = 43,562,579,467,364.99565
OK, there still seems to be a problem since the counts don't match!!??
So let's compute what the claimed credit is for both BM-T and FLOPCounting:
BM-T: Claimed Credit = ((I + F) * Runtime) / 1728000
Claimed Credit = 15.38
FLOPcounting: Claimed Credit = CF / 1.728E12
Claimed Credit = 25.21
Hmmm...
They still don't agree, what is going on??!!
Simple, this is what the whole flapdoodle is all about. The task was run with an optimized application and not one which is compliant with the definition of the Cobblestone.
Technically this is a simplification here, but the full technical explanation is one of the 'red herrings' rolled out by the Credit Anarchists (when they simplify it) to justify everybody just 'doing their own thing'.
For this specific host the 'Credit Multiplier' should be:
15.38 / 25.21 = X / 2.85 so solving for X;
X = (2.85 * 15.38) / 25.21 = 1.73
The current version of the issue has two parts:
1.) That multiplier is 'unique' to every single host, and the median of all current active hosts does NOT accurately reflect it for all hosts, since not all hosts have the same basic capabilities.
2.) The second part is political. The actual granted credit for this task was 50.44, and the real problem goes right back to when they made the choice to allow third party apps to run on the project without giving full thought to the ramifications of what that would mean in the context of relying on BM-T as the basis for the scoring system.
Finally, WRT to what I interpreted what Eric wanted to use the EFM for. It was to compensate for the known non-linearities in the FLOP vs Angle Range curve which has always existed for SAH.
Alinator
Credit News Update Does
)
Credit News Update
Does this ring a bell for long time EAH Crunchers? ;-)
Alinator
That is one reason why I am
)
That is one reason why I am happy with server side credits. No worries about client or app user ¨adjusted credit¨, if you know what I mean.
RE: That is one reason why
)
LOL...
I agree, and since I am from Missouri...
I have far more confidence that here at EAH this has been better thought out, not only in terms of this project, but in terms of the effect of what they do here has on the BOINC context as a whole.
This is the reason that I believe that what was set for the basis to convert work to Cobblestones back when S5 started accurately represented what the by that time inflated value of the Cobblestone currently was.
Therefore, since reducing the basis raises questions just better left unasked, for completely unscientific reasons; Why should EAH break from that and make any corrections to the basis here just to comply with what SAH is doing, when the hypothesis for why they are doing it has been disproved?
Alinator
RE: Credit News
)
The key pieces are:
1) Is the application open-source or not?
2) Is the optimized application returning valid scientific results?
If the answer to #1 is yes, then if #2 is also yes, then if he wants to keep it to himself, it breaks only the "spirit" of open-source, not the "letter" of it, so I'd think that if he kept it to himself in that instance, the project's actions are unfair and they caved to a bunch of complaining/jealousy.
If the answer to #1 is yes, but #2 is no, then clearly the app's usage needs to be discontinued and/or that project would need to go to a quorum of 2.
If the answer to #1 is no, then there's no further discussion. The app's usage should be forbidden and the project leadership should take measures to ensure that it doesn't happen again...whatever those measures may be.
RE: RE: Credit News
)
I was about to write something on this, but then I changed my mind because I think that this should really best be discussed in the MW@H forum. It's an important matter, no question. I would recommend that anyone interested in this controversy uses the MW@H forum search function to look for the keywords "open source" to find previous statements of the project devs and scientists on this matter and discuss their reaction now....but not here, please do that in the MW@H forum where the key stakeholders in this question can read it :-).
CU
Bikeman
RE: but not here, please do
)
Understand, but to do so, I'd have to attach...which would blow my semi-sorta "street cred" of not being someone that chased credits...since they would probably be the top credit awarder now that Cosmology has tanked...
Not only that, but I suspect the discussion amongst parties already present there will be...borderline non-kid-friendly based on the histoire of the similar issue at SETI some years ago...
However, I'll leave it be on these boards... :-)
wow hot under the coller are
)
wow
hot under the coller are we not
nice to see how we are progresing by credits
but thats all thay are
if thay were GDP or USD then problems
what ever keep crunsing
gaz
RE: Credit News
)
Phew!
Yup. Been there, done that. The open source app question was resolved a while ago here at E@H. Also 'optimised' clients have been made irrelevant. I agree with Bikeman, let's leave the specifics of that one for the MW@H boards! :-)
Cheers, Mike.
( edit ) The general lessons/rules/decisions drawn out at E@H back then are several, including but not limited to:
- credit and science bearing executables are defined by the central 'authority' of the project's management, or if not are made irrelevant.
- volunteer users are not the project's management.
- it is better to explicitly define the boundaries of roles in advance and not in retrospect.
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