Although you won't be calibrating on other projects, you will be using the benchmark values found by the calibrating client. As these use benchmark code significantly optimized compared to the stock client, you will be claiming higher than you were on other projects.
archae86 thanks for you input........am confused a bit though......it looks like, and sounds like from other information I've read that the benchmark calibration, i.e. it's increased, is only done on the project if the calibration is turned on for that project.
it looks like, and sounds like from other information I've read that the benchmark calibration, i.e. it's increased, is only done on the project if the calibration is turned on for that project.
So am I assuming correctly that the increase in Gfpops won't occur if the calibration is not selected for a particular project?
In the line you quote, 1.02 Gfpops is the output of the trux benchmark code.
I think if you check you will find that the stock client benchmarks the same host at something appreciably less than 1.02.
So if you turn calibration off for a project, 1.02 won't get changed (nor will observed CPU time), but both the Gfpops _and_ the corresponding fixed point benchmark-not mentioned here but also important, are the value observed by trux--which I'm saying I think you'll find higher than the value observed by stock client.
I just want to say that I appreciate the comments I have read here about utilizing Truxoft. After seeing what Akos' U41.04 did to my CPU time.
On one series of WU, my claimed credit was 1.8 with 882 seconds to complete WU.
The credit I was claiming did pull down others who did so much more CPU time..I decided to give it a try...the first corrected CPU times were lower initially, but that quickly changed. The next 20 WU went from a claimed credit of ~8 to ~32 and still climbing. I now see the fairness for others who have not had the time or awareness to optimize their apps with Akos.
I just want to say that I appreciate the comments I have read here about utilizing Truxoft. After seeing what Akos' U41.04 did to my CPU time.
On one series of WU, my claimed credit was 1.8 with 882 seconds to complete WU.
The credit I was claiming did pull down others who did so much more CPU time..I decided to give it a try...the first corrected CPU times were lower initially, but that quickly changed. The next 20 WU went from a claimed credit of ~8 to ~32 and still climbing. I now see the fairness for others who have not had the time or awareness to optimize their apps with Akos.
Thanks again for the info here...
Thank you, Stan, for appreciating the impact of non-optimized CCs used in conjunction with Akos' Turbo-Apps upon quorums. Whereas we who run both are happy enough to lift those running only the Turbo-app, with wider use of Akos' work, it becomes statistically more probable that we will encounter two of them, and get dragged down by them.
Respects,
Michael R.
microcraft
"The arc of history is long, but it bends toward justice" - MLK
Thank you, Stan, for appreciating the impact of non-optimized CCs used in conjunction with Akos' Turbo-Apps upon quorums. Whereas we who run both are happy enough to lift those running only the Turbo-app, with wider use of Akos' work, it becomes statistically more probable that we will encounter two of them, and get dragged down by them.
Respects,
Michael R.
Ah yes, I have indeed encountered this (but only occasionally), and you know what? I don't mind it in the least. I would rather get credit dragged down by hyper-crunchers, than to drag down someone using the standard app who doesn't know any better. If we get to the point where the large majority use the optimized apps, and the standard client, I just might turn E@H calibrating off.
RE: Although you won't be
)
archae86 thanks for you input........am confused a bit though......it looks like, and sounds like from other information I've read that the benchmark calibration, i.e. it's increased, is only done on the project if the calibration is turned on for that project.
i.e.
5/7/2006 7:54:57 PM|Einstein@Home|CC calibration: 13.52 >> 19.97 (time: 6145s >> 6176s / Gfpops: 1.02 >> 2.81)
So am I assuming correctly that the increase in Gfpops won't occur if the calibration is not selected for a particular project?
This would be good!!
RE: it looks like, and
)
In the line you quote, 1.02 Gfpops is the output of the trux benchmark code.
I think if you check you will find that the stock client benchmarks the same host at something appreciably less than 1.02.
So if you turn calibration off for a project, 1.02 won't get changed (nor will observed CPU time), but both the Gfpops _and_ the corresponding fixed point benchmark-not mentioned here but also important, are the value observed by trux--which I'm saying I think you'll find higher than the value observed by stock client.
I just want to say that I
)
I just want to say that I appreciate the comments I have read here about utilizing Truxoft. After seeing what Akos' U41.04 did to my CPU time.
On one series of WU, my claimed credit was 1.8 with 882 seconds to complete WU.
The credit I was claiming did pull down others who did so much more CPU time..I decided to give it a try...the first corrected CPU times were lower initially, but that quickly changed. The next 20 WU went from a claimed credit of ~8 to ~32 and still climbing. I now see the fairness for others who have not had the time or awareness to optimize their apps with Akos.
Thanks again for the info here...
RE: I just want to say that
)
Thank you, Stan, for appreciating the impact of non-optimized CCs used in conjunction with Akos' Turbo-Apps upon quorums. Whereas we who run both are happy enough to lift those running only the Turbo-app, with wider use of Akos' work, it becomes statistically more probable that we will encounter two of them, and get dragged down by them.
Respects,
Michael R.
microcraft
"The arc of history is long, but it bends toward justice" - MLK
Michael, good to hear from
)
Michael, good to hear from you again...
I do see your point as regards two people using Akos apps without Optimized BOINC in a quorum. That would certainly drag us down...
But, still, I am pleased to have my crunching time per WU reduced so greatly.
This work with Einstein has been so much more interesting.
Hope you are feeling better ....Stan
RE: Michael, good to hear
)
I don't see there's anything much that drags you down except granted credits....
RE: Thank you, Stan, for
)
Ah yes, I have indeed encountered this (but only occasionally), and you know what? I don't mind it in the least. I would rather get credit dragged down by hyper-crunchers, than to drag down someone using the standard app who doesn't know any better. If we get to the point where the large majority use the optimized apps, and the standard client, I just might turn E@H calibrating off.
Seti Classic Final Total: 11446 WU.
Randy, I concur with your
)
Randy, I concur with your views....Stan
Just another
)
Just another issue.
Currently the latest recommended version is 5.4.9, but trux lastest version is still 5.3.12.
I would like to use a calibrating 5.4.x version.
Does someone has a information?
Thanks
Achim
RE: Just another
)
As far as I know it doesn't yet exist and I'm not sure if he'll be doing one.
Kathryn :o)
Einstein@Home Moderator