Thank you for asking for counterviews. I hope that I've adequately expressed mine. :-)
Respects,
Michael R.
Michael, thanks for the views, I'm taking them into consideration. I've read a little about what the optimized clients do, and their benefits for users using optimized apps, but what about my other projects that don't have an optimized app?
Will I be claiming excessive points for those projects if run with the optimized clients?
I think the number of results processed of stable type since the client started up is relevant, not the number of days. As I mentioned, about thirty is a decent expectation to get near the final result, and going the "wrong" direction for a dozen or more is common.
The worst I have seen was when I already was running the calibrated client, then switched from the stock science ap to a 4x faster akosf offering. The calibration system had more "unlearning" to do, so took something like 30 results just to go into positive claim, and a couple dozen more to get near stability.
Trux has to do that, however, to get decent behavior in the face of abnormal individual results. For example, in SETI, some WU's take much more or much less effort to compute than typical for the estimate sent down. Also, in a Pentium III running Win98, you'll get much variation in reported CPU time if there are certain other activities on the machine running. (my weekly example is Norton virus scan, which adds something like an hour and a half to what otherwise is a three hour CPU time). If you have something like this going on for your Pentium III, it could be part of the issue. The Einstein science ap CPU time claim appears much more stable against other process effects on the system under WinXP than under Win98 (very much, actually).
I understand all of this, and I appreciate the responses. I've been noticing weird behavior with this particular setup, beyond what I mentioned earlier. Just a few results ago, the truxoft client started adjusting the resultant CPU time due to "calibration."
Unfortunately for me, the stdoutae file shows that the negative calibration limit was blocked, but the results are showing the opposite. My CPU time is being adjusted downward to claim less credit. For instance, see this result. I'm also noticing things like the network reminder frequency being "stuck" at 60 minutes. I can change it in options, and as soon as I close the options window and reopen it, it's right back at 60.
I'm somewhat puzzled by all of this, and any help is appreciated again. If it helps, it's a PIII 667 Coppermine running Win2k SP4.
Just a few results ago, the truxoft client started adjusting the resultant CPU time due to "calibration."
Unfortunately for me, the stdoutae file shows that the negative calibration limit was blocked, but the results are showing the opposite. My CPU time is being adjusted downward to claim less credit. For instance, see this result.
You are seeing what we all saw (at least those who checked along the way).
If you check your most recent CPU benchmark in the message log (_don't_ consult the data in the Einstein web page for this host)I think you'll find that the adjusted mfpops for this host shown in the stderr you point to is already adjusted up. Yes, the time at this stage is adjusted down. The net is already up, else it would not have been applied. From this point, if your case is likes the rest of ours (and so far it is) you'll see a steady progression, less and less reduction of cpu time plus more and more upping of the "benchmarked" floating point rating, later crossing into both being adjusted in the positive direction.
I don't recognize your terminology regarding "network reminder frequency" and "options". If it is the "Connect to network about every" parameter, then one changes it in the general preferences page at the project web site, which is not a function of the client at all, so can hardly relate to the credit concern.
Unfortunately for me, the stdoutae file shows that the negative calibration limit was blocked, but the results are showing the opposite. My CPU time is being adjusted downward to claim less credit.
I don't know why, but it's known to occasionally diverge somewhat before finally converging on the targeted value a few dozen wu's later.
I don't recognize your terminology regarding "network reminder frequency" and "options". If it is the "Connect to network about every" parameter, then one changes it in the general preferences page at the project web site, which is not a function of the client at all, so can hardly relate to the credit concern.
In the BOINC Manager, if you click Options (or alt-o), then Options, under the General tab, Reminder Frequency. With it set at 0, it never asks how it should connect to the internet. The default of 60 can hang results occasionally while awaiting a user response on how to connect. I've already set the network to be always available under the Commands tab (alt-c), but it still asks because the reminder frequency is stuck at 60. This doesn't affect any result in any way, it's just irritating to find 3 WUs ready to report but thinking there's no connection available and no new WUs downloading.
Just a few results ago, the truxoft client started adjusting the resultant CPU time due to "calibration."
Unfortunately for me, the stdoutae file shows that the negative calibration limit was blocked, but the results are showing the opposite. My CPU time is being adjusted downward to claim less credit. For instance, see this result.
You are seeing what we all saw (at least those who checked along the way).
Overnight your client has continued to move its credit adjustment in the expected direction. In particular, the CPU adjustment on the latest result is essentially break even (3016 changed to 3015) instead of the 18% reduction of a result of few steps back. Also the floating point benchmark adjustment has moved further up, with the latest result reporting 1659 Mfpops, up from 1157.
Also it is worthing noticing that with essentially identical true CPU time, the result a few steps back claimed 4.04 cobblestones, while the latest claimed 5.79. As these are short Work Units, I think "fair claim" is something like 11, so you are now making rapid progress in the desired direction.
so basically there are a bazillion different variations on how to look at things......I'm more concerned with turning out as much work as possible. If there is a potential credit loss with being able to crank out units 5x's faster, I'm cool with that.
Sticking with Akosf's apps, and the standard BOINC client for now.
After reading further and taking things into consideration, I've decided that I should use Trux's Calibrating Client to adjust the Einstein credits.
I was able to see where I was kind of sticking it to others not using the optimized apps when two of us were........they'd claim 40 something points, we'd claim like 15, and the granted would fall to the 15.....cheating the other individual out of points.
I did figure out how to set the calibration for only Einstein since that is the only project I have current with an optimized application. My other projects will claim credit the standard way I presume.
Also like the ability to report results immediately!
now I'm completing units like mad and working on claiming credits that are fair to other users of Einstein...
I was able to see where I was kind of sticking it to others not using the optimized apps when two of us were........they'd claim 40 something points, we'd claim like 15, and the granted would fall to the 15.....cheating the other individual out of points.
I did figure out how to set the calibration for only Einstein since that is the only project I have current with an optimized application. My other projects will claim credit the standard way I presume.
I agree with your comments on the fairness aspect.
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.
If some of these strike you as "too high" (SETI won't be too high if you are using a decent science ap) you have little recourse. Turning on calibration for the "too high" project won't help, as tx36 does not do downward adjust on non-SETI projects.
If you see "too low" (which you certainly will if you are running SETI crunch3r on a modern machine), then turning on calibration for that project probably will help after a few dozen results. Calibration is separate for each project.
I did figure out how to set the calibration for only Einstein since that is the only project I have current with an optimized application. My other projects will claim credit the standard way I presume.
Yes, you're presuming right. :-)
Thanks to you for seeing the downwards to other users.
the trux ccc has some nice features, as you rewarded the immediate report there are others, too:
If you got an HT enabled cpu and taking part in at least one other project (let's say Seti@Home) than EaH, you can speed up crunching time by using this line in your truxoft_prefs.xml
Einstein@Home,SETI@Home
That way you crunch Einstein on one (logical) cpu and seti on the other. Due to different overheads the cashes are used in a much more efficient way and the crunching time decreases again... ;-)
RE: Thank you for asking
)
Michael, thanks for the views, I'm taking them into consideration. I've read a little about what the optimized clients do, and their benefits for users using optimized apps, but what about my other projects that don't have an optimized app?
Will I be claiming excessive points for those projects if run with the optimized clients?
RE: I think the number of
)
I understand all of this, and I appreciate the responses. I've been noticing weird behavior with this particular setup, beyond what I mentioned earlier. Just a few results ago, the truxoft client started adjusting the resultant CPU time due to "calibration."
Unfortunately for me, the stdoutae file shows that the negative calibration limit was blocked, but the results are showing the opposite. My CPU time is being adjusted downward to claim less credit. For instance, see this result. I'm also noticing things like the network reminder frequency being "stuck" at 60 minutes. I can change it in options, and as soon as I close the options window and reopen it, it's right back at 60.
I'm somewhat puzzled by all of this, and any help is appreciated again. If it helps, it's a PIII 667 Coppermine running Win2k SP4.
RE: Just a few results
)
You are seeing what we all saw (at least those who checked along the way).
previous description
If you check your most recent CPU benchmark in the message log (_don't_ consult the data in the Einstein web page for this host)I think you'll find that the adjusted mfpops for this host shown in the stderr you point to is already adjusted up. Yes, the time at this stage is adjusted down. The net is already up, else it would not have been applied. From this point, if your case is likes the rest of ours (and so far it is) you'll see a steady progression, less and less reduction of cpu time plus more and more upping of the "benchmarked" floating point rating, later crossing into both being adjusted in the positive direction.
I don't recognize your terminology regarding "network reminder frequency" and "options". If it is the "Connect to network about every" parameter, then one changes it in the general preferences page at the project web site, which is not a function of the client at all, so can hardly relate to the credit concern.
RE: Unfortunately for me,
)
I don't know why, but it's known to occasionally diverge somewhat before finally converging on the targeted value a few dozen wu's later.
RE: I don't recognize your
)
In the BOINC Manager, if you click Options (or alt-o), then Options, under the General tab, Reminder Frequency. With it set at 0, it never asks how it should connect to the internet. The default of 60 can hang results occasionally while awaiting a user response on how to connect. I've already set the network to be always available under the Commands tab (alt-c), but it still asks because the reminder frequency is stuck at 60. This doesn't affect any result in any way, it's just irritating to find 3 WUs ready to report but thinking there's no connection available and no new WUs downloading.
RE: RE: I don't recognize
)
Sorry, I never played with that one, and don't know whether client behavior might foul it up. I should have looked around more before posting. Sorry.
RE: RE: Just a few
)
Overnight your client has continued to move its credit adjustment in the expected direction. In particular, the CPU adjustment on the latest result is essentially break even (3016 changed to 3015) instead of the 18% reduction of a result of few steps back. Also the floating point benchmark adjustment has moved further up, with the latest result reporting 1659 Mfpops, up from 1157.
I'm commenting on:
result 28095246 as the "latest result"
and:
result 28013534 as "result a few steps back".
Also it is worthing noticing that with essentially identical true CPU time, the result a few steps back claimed 4.04 cobblestones, while the latest claimed 5.79. As these are short Work Units, I think "fair claim" is something like 11, so you are now making rapid progress in the desired direction.
RE: so basically there are
)
After reading further and taking things into consideration, I've decided that I should use Trux's Calibrating Client to adjust the Einstein credits.
I was able to see where I was kind of sticking it to others not using the optimized apps when two of us were........they'd claim 40 something points, we'd claim like 15, and the granted would fall to the 15.....cheating the other individual out of points.
I did figure out how to set the calibration for only Einstein since that is the only project I have current with an optimized application. My other projects will claim credit the standard way I presume.
Also like the ability to report results immediately!
now I'm completing units like mad and working on claiming credits that are fair to other users of Einstein...
RE: I was able to see where
)
I agree with your comments on the fairness aspect.
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.
If some of these strike you as "too high" (SETI won't be too high if you are using a decent science ap) you have little recourse. Turning on calibration for the "too high" project won't help, as tx36 does not do downward adjust on non-SETI projects.
If you see "too low" (which you certainly will if you are running SETI crunch3r on a modern machine), then turning on calibration for that project probably will help after a few dozen results. Calibration is separate for each project.
RE: I did figure out how to
)
Yes, you're presuming right. :-)
Thanks to you for seeing the downwards to other users.
the trux ccc has some nice features, as you rewarded the immediate report there are others, too:
If you got an HT enabled cpu and taking part in at least one other project (let's say Seti@Home) than EaH, you can speed up crunching time by using this line in your truxoft_prefs.xml
Einstein@Home,SETI@Home
That way you crunch Einstein on one (logical) cpu and seti on the other. Due to different overheads the cashes are used in a much more efficient way and the crunching time decreases again... ;-)
AndyK
Want to know your pending credit?
The biggest bug is sitting 10 inch in front of the screen.