well I'm looking forwatd to the new way of measuring work done !
for the moment BOINC is off this box, but plan on doing a skinny linux install shortly, specifically for Einstein (grin). Any idea when the new measuring system will be implemented ?
well I'm looking forwatd to the new way of measuring work done !
for the moment BOINC is off this box, but plan on doing a skinny linux install shortly, specifically for Einstein (grin). Any idea when the new measuring system will be implemented ?
Gray
Nope, sorry. There was more traffic about it a month to three months ago, and it's been kicking around for a few more than that, but it seems to have taken a back burner position lately. They've been working on the upcoming Account Management System more lately, because it's going to be part of the 5.4.x BOINC official release. Once we see the new BOINC out of beta and official, I think they'll take up the still-difficult job of equitable "payment". Even then, it may not have the same impetus, because one of the most vocal proponents was Paul Buck, who has withdrawn in disgust and frustration from all things BOINC.
Wish I could paint a rosier picture.
microcraft
"The arc of history is long, but it bends toward justice" - MLK
My CPU benchmarks are now a lot higher than what they were. Dhrystone is roughly double what it was.
Wont take long to see if there is a difference. Using a 3GB HT CPU so I am doing 2 units roughly every 2hrs 45min. Well on the other version at least. Be interesting to see if there is a difference using this version of boinc with the truXoft.
Only changing an optimized science app will show differences in WU times (over and above their normal variation). Changing the BOINC Client like you did will not have any effect.
I thought that this was the case but one can hope ;) Still running at 2hrs 45min. Have submitted 2 units so far and on both of them the claimed credit was +-20% higher than without the truXoft installed. Will keep monitoring as it can supposedly take up to 30 units to stabalize.
Well, I'm still going to do the linux install - even if I don't get the recognition for large amounts of cpu cycles - it will still be the usual speed tweak attempt to get the time taken per WU as low as possible - maybe I can beat the times given by RD (grin).
Hey guys,
I remember reading somewhere that the original credit value for a days crunching was 100 cobblestones. Not sure if this number is correct but it will do for now.
Regardless of the speed of your machine and thus the number of workunits you crunch in a day, you were to get 100 cobblestones in credit.
Now if you only crunch 4 WU's a day you would get 25 credit each. 10 WU's would get 10 credit each. Thus the 100 credit per day.
The quorum alters this system in that the high and low claims are discarded and the middle one granted. Therefor the quicker you complete a WU, the better your chances are that your claim will be the low claim, thus discarded.
So go right ahead, over state you bench marks to your hearts content. I'll stick to akosf's app and the standard client. ;)
Will keep monitoring as it can supposedly take up to 30 units to stabalize.
Once the TruXoft tx36 client starts upclaiming, some of the detail (observed and tampered CPU time for the result, tampered Fpops rating) is logged to stderr out. Until then, the calibration activity is best observed by looking at the message log in BOINCmgr. You'll see a message something like "negative calibration blocked" followed by an indication of what the revised CPU, Fpop, and cobblestone claim would have been. As calibration continues, you'll see the "would have been" cobblestone claim rise toward parity, at which point upclaiming logged in stderr out will begin. Any apparent upclaiming before then is the consequence of higher benchmark results, not of the calibration process.
The rationale behind FLOP counting is exactly the same as what lies behind the present system, just more accurately counted and platform-agnostic, to further level the playing field. If FLOPs are counted, a slower computer will get exactly the same credit as a faster one, per amount of work done.
M.R.:
More accurately counted? That's surely a joke! Since when does the present Boinc system accurately count anything? I mean with reference to a 'roll your own' client.
Perhaps I wasn't clear enough - a faster computer will have a higher RAC - that means it will do more FLOPs per hour yielding more credits per hour. In fact, at SETI Beta there has already been some talk about the 'poor' performance of slow computers in terms of credits earned per hour. I'm not talking about the quality of the work, only the quantity. Credits will remain a significant motivating factor.
You are clearly naive in your understanding of human behavior.
The rationale behind FLOP counting is exactly the same as what lies behind the present system, just more accurately counted and platform-agnostic, to further level the playing field. If FLOPs are counted, a slower computer will get exactly the same credit as a faster one, per amount of work done.
M.R.:
More accurately counted? That's surely a joke! Since when does the present Boinc system accurately count anything? I mean with reference to a 'roll your own' client.
Perhaps I wasn't clear enough - a faster computer will have a higher RAC - that means it will do more FLOPs per hour yielding more credits per hour. In fact, at SETI Beta there has already been some talk about the 'poor' performance of slow computers in terms of credits earned per hour. I'm not talking about the quality of the work, only the quantity. Credits will remain a significant motivating factor.
You are clearly naive in your understanding of human behavior.
Perhaps M.R. refers to flops counting by the science app not the Boinc client. Isn't the assumption (theory) that when the science app does the counting it negates all those tweaked (Boinc) clients that people like so much and also levels the playing field? I don't know that flops counting by the app has been shown to be feasible or practical.
Aside: A pet peeve of mine is the tiresome use of the phrase "the client" when referring to the science app. It's tiresome because it's inaccurate and requires readers to infer what the author really means. Interpretation leads to mis-understanding which leads to unfriendly and aggressive language in their posts. (Then again, I suppose some people thrive on that sort of thing,IMO.)
I've never quite understood the reasoning behind the need to "level the playing field". If someones 'puters are faster than mine, and most are, and they turn in more WU's, so what! I'd settle for a simple WU count. Long ones, short ones, who cares, it's all relative to the project(s) you are working on. Climate takes a long time for each WU, Seti takes way less time, and everyone know that. Cobblestones and RAC don't tell you anything about what your actual 'puters are doing because the credit you receive may not even be close to what is claimed by your boxes. Both RAC and cobblestones on mine are way out of line right now because I'm using the new science app on everything. At least 90% of the time my claimed credit is tossed because it's very low, so most of the time credit granted and RAC are total garbage because they are based on what someone else claimed!
Perhaps M.R. refers to flops counting by the science app not the Boinc client. Isn't the assumption (theory) that when the science app does the counting it negates all those tweaked (Boinc) clients that people like so much and also levels the playing field? I don't know that flops counting by the app has been shown to be feasible or practical.
I don't know where the Flops get counted in SETI Enhanced, but I do know that I'm using a more-or-less standard client (BOINC Menubar v5.2.13), which didn't require updating when I attached to S@h Beta. So AFAICT either the project enables a function of the BOINC client that's normally unused, or it's the app that does the counting.
The credit claims I've seen so far there generally agree to the nearest percent or better, even when the ratios between processing times on various hosts approach an order of magnitude. In the only exception I've noticed, the 'odd man out' was running an older BOINC client than the others, v4.x--which would indeed tend to support the former hypothesis above.
Hiya Michael and RD. well
)
Hiya Michael and RD.
well I'm looking forwatd to the new way of measuring work done !
for the moment BOINC is off this box, but plan on doing a skinny linux install shortly, specifically for Einstein (grin). Any idea when the new measuring system will be implemented ?
Gray
RE: Hiya Michael and
)
Nope, sorry. There was more traffic about it a month to three months ago, and it's been kicking around for a few more than that, but it seems to have taken a back burner position lately. They've been working on the upcoming Account Management System more lately, because it's going to be part of the 5.4.x BOINC official release. Once we see the new BOINC out of beta and official, I think they'll take up the still-difficult job of equitable "payment". Even then, it may not have the same impetus, because one of the most vocal proponents was Paul Buck, who has withdrawn in disgust and frustration from all things BOINC.
Wish I could paint a rosier picture.
microcraft
"The arc of history is long, but it bends toward justice" - MLK
RE: RE: My CPU
)
I thought that this was the case but one can hope ;) Still running at 2hrs 45min. Have submitted 2 units so far and on both of them the claimed credit was +-20% higher than without the truXoft installed. Will keep monitoring as it can supposedly take up to 30 units to stabalize.
Hello Michael Well, I'm
)
Hello Michael
Well, I'm still going to do the linux install - even if I don't get the recognition for large amounts of cpu cycles - it will still be the usual speed tweak attempt to get the time taken per WU as low as possible - maybe I can beat the times given by RD (grin).
Gray
Hey guys, I remember reading
)
Hey guys,
I remember reading somewhere that the original credit value for a days crunching was 100 cobblestones. Not sure if this number is correct but it will do for now.
Regardless of the speed of your machine and thus the number of workunits you crunch in a day, you were to get 100 cobblestones in credit.
Now if you only crunch 4 WU's a day you would get 25 credit each. 10 WU's would get 10 credit each. Thus the 100 credit per day.
The quorum alters this system in that the high and low claims are discarded and the middle one granted. Therefor the quicker you complete a WU, the better your chances are that your claim will be the low claim, thus discarded.
So go right ahead, over state you bench marks to your hearts content. I'll stick to akosf's app and the standard client. ;)
RE: Will keep monitoring as
)
Once the TruXoft tx36 client starts upclaiming, some of the detail (observed and tampered CPU time for the result, tampered Fpops rating) is logged to stderr out. Until then, the calibration activity is best observed by looking at the message log in BOINCmgr. You'll see a message something like "negative calibration blocked" followed by an indication of what the revised CPU, Fpop, and cobblestone claim would have been. As calibration continues, you'll see the "would have been" cobblestone claim rise toward parity, at which point upclaiming logged in stderr out will begin. Any apparent upclaiming before then is the consequence of higher benchmark results, not of the calibration process.
RE: The rationale behind
)
M.R.:
More accurately counted? That's surely a joke! Since when does the present Boinc system accurately count anything? I mean with reference to a 'roll your own' client.
Perhaps I wasn't clear enough - a faster computer will have a higher RAC - that means it will do more FLOPs per hour yielding more credits per hour. In fact, at SETI Beta there has already been some talk about the 'poor' performance of slow computers in terms of credits earned per hour. I'm not talking about the quality of the work, only the quantity. Credits will remain a significant motivating factor.
You are clearly naive in your understanding of human behavior.
RE: RE: The rationale
)
Perhaps M.R. refers to flops counting by the science app not the Boinc client. Isn't the assumption (theory) that when the science app does the counting it negates all those tweaked (Boinc) clients that people like so much and also levels the playing field? I don't know that flops counting by the app has been shown to be feasible or practical.
Aside: A pet peeve of mine is the tiresome use of the phrase "the client" when referring to the science app. It's tiresome because it's inaccurate and requires readers to infer what the author really means. Interpretation leads to mis-understanding which leads to unfriendly and aggressive language in their posts. (Then again, I suppose some people thrive on that sort of thing,IMO.)
I've never quite understood
)
I've never quite understood the reasoning behind the need to "level the playing field". If someones 'puters are faster than mine, and most are, and they turn in more WU's, so what! I'd settle for a simple WU count. Long ones, short ones, who cares, it's all relative to the project(s) you are working on. Climate takes a long time for each WU, Seti takes way less time, and everyone know that. Cobblestones and RAC don't tell you anything about what your actual 'puters are doing because the credit you receive may not even be close to what is claimed by your boxes. Both RAC and cobblestones on mine are way out of line right now because I'm using the new science app on everything. At least 90% of the time my claimed credit is tossed because it's very low, so most of the time credit granted and RAC are total garbage because they are based on what someone else claimed!
RE: Perhaps M.R. refers to
)
I don't know where the Flops get counted in SETI Enhanced, but I do know that I'm using a more-or-less standard client (BOINC Menubar v5.2.13), which didn't require updating when I attached to S@h Beta. So AFAICT either the project enables a function of the BOINC client that's normally unused, or it's the app that does the counting.
The credit claims I've seen so far there generally agree to the nearest percent or better, even when the ratios between processing times on various hosts approach an order of magnitude. In the only exception I've noticed, the 'odd man out' was running an older BOINC client than the others, v4.x--which would indeed tend to support the former hypothesis above.