I've been using Crunch3r's client. Is the Truxoft calibrating client better in the viewpoint of calibration? Or is the differences small enough to be negligible? I've also seen some posts on BoincStudio and the resulting credit thereof to me seems to be rather excessive.
I've been using Crunch3r's client. Is the Truxoft calibrating client better in the viewpoint of calibration? Or is the differences small enough to be negligible? I've also seen some posts on BoincStudio and the resulting credit thereof to me seems to be rather excessive.
Truxoft's aims to normalize the credit, nothing more. It seems to look for the average, and then calibrate until it achieves that figure, and nothing more excessive.
Michael R.
microcraft
"The arc of history is long, but it bends toward justice" - MLK
Truxoft's aims to normalize the credit, nothing more. It seems to look for the average, and then calibrate until it achieves that figure, and nothing more excessive.
Truxoft's client is doing fine on my Athlon64 3700+, but I'm having some calibration troubles on my PIII 667. I'm using S41.07 on the PIII and crunching about as expected, but even the calibrating client is reporting claimed credit of 3-11. I also notice that when I check the results for each unit on that machine, the typical messages about real vs corrected CPU time aren't present, and neither is the corrected Mfpops message.
Truxoft's aims to normalize the credit, nothing more. It seems to look for the average, and then calibrate until it achieves that figure, and nothing more excessive.
Truxoft's client is doing fine on my Athlon64 3700+, but I'm having some calibration troubles on my PIII 667. I'm using S41.07 on the PIII and crunching about as expected, but even the calibrating client is reporting claimed credit of 3-11. I also notice that when I check the results for each unit on that machine, the typical messages about real vs corrected CPU time aren't present, and neither is the corrected Mfpops message.
Has anyone seen this or have any advice?
Have you turned on calibration??? I believe if you follow the instructions on installing the windows version, the zip file also puts a file in place to turn on calibration. There's no such file for linux, which I ran into this issue on my linux boxes. I did a few WUs before finding the file to modify to turn on calibration.
And for others as far as Trux's calibration, once it's normalized, it actually underclaims a tiny bit compared to stock client and science app. I'm not complaining, as it makes sense to be a little conservative on calibration to not ruffle peoples feathers.
I'm using S41.07 on the PIII and crunching about as expected, but even the calibrating client is reporting claimed credit of 3-11. I also notice that when I check the results for each unit on that machine, the typical messages about real vs corrected CPU time aren't present, and neither is the corrected Mfpops message.
Has anyone seen this or have any advice?
If the calibration would be a downward adjust, for non-SETI projects it is inhibited.
It is pretty common for the calibration to take about 30 results to stabilize when it is applied from scratch to a consistent stream of work. During the early part, it can actually head in the wrong direction. It appears that your Pentium III may be early days yet.
At this stage, there would normally be a message in your message log, but not in stderr if the case were the one I am suggesting. Have you checked the message log?
Well, I checked the truxoft_prefs file, and it does have calibration enabled. The message log shows that it did run benchmarks at startup and each result has a negative calibration limit blocked.
However, my Athlon 64 has the same messages in its log, but the calibration produces credit claims that are reasonable. The PIII has been crunching for about 2 days now and still is claiming credit of 3 (short WU) to 14 (long WU).
Well, I checked the truxoft_prefs file, and it does have calibration enabled. The message log shows that it did run benchmarks at startup and each result has a negative calibration limit blocked.
However, my Athlon 64 has the same messages in its log, but the calibration produces credit claims that are reasonable. The PIII has been crunching for about 2 days now and still is claiming credit of 3 (short WU) to 14 (long WU).
I had the same issue with my PII. I believe that trux takes longer to calibrate on older machines. I was getting the same "negative CC, calibration blocked" error as you, just let it do its thing, and in a couple of days you should be claiming higher credits.
There are 10^11 stars in the galaxy. That used to be a huge number. But it's only a hundred billion. It's less than the national deficit! We used to call them astronomical numbers. Now we should call them economical numbers. - Richard Feynman
The message log shows that it did run benchmarks at startup and each result has a negative calibration limit blocked.
However, my Athlon 64 has the same messages in its log, but the calibration produces credit claims that are reasonable. The PIII has been crunching for about 2 days now and still is claiming credit of 3 (short WU) to 14 (long WU).
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).
30 results seems to be quite a common value, all my boxes needed about that until they reached an average claim per result.
But then the P2_0550 and J2_0550 WUs came ... and it started learning again.
Long and short standard Albert WUs do not confuse the "experience" of the calibration as they have about the same relation between estimated and real CPU time - but those long ones have been estimated wrong, wich caused the client to complain about "exaggerated" claiming first - and when those special WUs were over, it restarted learning with "negative calibration limit".
So a realistic calibration really needs a constant ratio between estimated and real time.
30 results seems to be quite a common value, all my boxes needed about that until they reached an average claim per result.
But then the P2_0550 and J2_0550 WUs came ... and it started learning again.
Long and short standard Albert WUs do not confuse the "experience" of the calibration as they have about the same relation between estimated and real CPU time - but those long ones have been estimated wrong, wich caused the client to complain about "exaggerated" claiming first - and when those special WUs were over, it restarted learning with "negative calibration limit".
So a realistic calibration really needs a constant ratio between estimated and real time.
Yes indeed. I've only had one "pj" and all by itself it caused at least a 25% temporary shift in the claim ratio for the host that processed it. That was why I mentioned "consistent stream of work" in earlier comments. SETI's noisy units and other oddities have meant much more variation in the past than Einstein, so the p and j units have probably messed up behavior on a lot of Calibrating Client users who have been seeing stable behavior.
RE: Truxoft's calibrating
)
I've been using Crunch3r's client. Is the Truxoft calibrating client better in the viewpoint of calibration? Or is the differences small enough to be negligible? I've also seen some posts on BoincStudio and the resulting credit thereof to me seems to be rather excessive.
RE: RE: Truxoft's
)
Truxoft's aims to normalize the credit, nothing more. It seems to look for the average, and then calibrate until it achieves that figure, and nothing more excessive.
Michael R.
microcraft
"The arc of history is long, but it bends toward justice" - MLK
RE: Truxoft's aims to
)
Truxoft's client is doing fine on my Athlon64 3700+, but I'm having some calibration troubles on my PIII 667. I'm using S41.07 on the PIII and crunching about as expected, but even the calibrating client is reporting claimed credit of 3-11. I also notice that when I check the results for each unit on that machine, the typical messages about real vs corrected CPU time aren't present, and neither is the corrected Mfpops message.
Has anyone seen this or have any advice?
RE: RE: Truxoft's aims to
)
Have you turned on calibration??? I believe if you follow the instructions on installing the windows version, the zip file also puts a file in place to turn on calibration. There's no such file for linux, which I ran into this issue on my linux boxes. I did a few WUs before finding the file to modify to turn on calibration.
And for others as far as Trux's calibration, once it's normalized, it actually underclaims a tiny bit compared to stock client and science app. I'm not complaining, as it makes sense to be a little conservative on calibration to not ruffle peoples feathers.
RE: I'm using S41.07 on
)
If the calibration would be a downward adjust, for non-SETI projects it is inhibited.
It is pretty common for the calibration to take about 30 results to stabilize when it is applied from scratch to a consistent stream of work. During the early part, it can actually head in the wrong direction. It appears that your Pentium III may be early days yet.
At this stage, there would normally be a message in your message log, but not in stderr if the case were the one I am suggesting. Have you checked the message log?
Well, I checked the
)
Well, I checked the truxoft_prefs file, and it does have calibration enabled. The message log shows that it did run benchmarks at startup and each result has a negative calibration limit blocked.
However, my Athlon 64 has the same messages in its log, but the calibration produces credit claims that are reasonable. The PIII has been crunching for about 2 days now and still is claiming credit of 3 (short WU) to 14 (long WU).
RE: Well, I checked the
)
I had the same issue with my PII. I believe that trux takes longer to calibrate on older machines. I was getting the same "negative CC, calibration blocked" error as you, just let it do its thing, and in a couple of days you should be claiming higher credits.
There are 10^11 stars in the galaxy. That used to be a huge number. But it's only a hundred billion. It's less than the national deficit! We used to call them astronomical numbers. Now we should call them economical numbers. - Richard Feynman
RE: The message log shows
)
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).
30 results seems to be quite
)
30 results seems to be quite a common value, all my boxes needed about that until they reached an average claim per result.
But then the P2_0550 and J2_0550 WUs came ... and it started learning again.
Long and short standard Albert WUs do not confuse the "experience" of the calibration as they have about the same relation between estimated and real CPU time - but those long ones have been estimated wrong, wich caused the client to complain about "exaggerated" claiming first - and when those special WUs were over, it restarted learning with "negative calibration limit".
So a realistic calibration really needs a constant ratio between estimated and real time.
RE: 30 results seems to be
)
Yes indeed. I've only had one "pj" and all by itself it caused at least a 25% temporary shift in the claim ratio for the host that processed it. That was why I mentioned "consistent stream of work" in earlier comments. SETI's noisy units and other oddities have meant much more variation in the past than Einstein, so the p and j units have probably messed up behavior on a lot of Calibrating Client users who have been seeing stable behavior.