I've seen bubbly glowing effusive testimonials about optimized SETI/BOINC software, and in particular CrunchR's variants, but I've now tried those and on my system the results are much more modest, maybe even counterproductive. I'm wondering if there's a tuning or other issue that I can change to have similarly wondrous results.

My current system uses an AMD Athlon XP 2500+, MSI K7N2G-ILSR motherboard, and 2x512MB Mushkin PC3200 DDR400 RAM modules as dual DDR. I have modestly overclocked the CPU by about 7% using just the FSB pushed from 166/333 to 179/358. The system is also watercooled with a Koolance Exos. The RAM is underclocked with that, and I suspect I could do better by reducing the CPU multiplier and increasing the FSB to 200/400. I would have already tried it, but only the CPU is watercooled right now and the chipset/onboard GPU shows hints of being the weak link; I have a water block for that as well, but need to install it.

After doing my best to understand and follow the very limited instructions, I saw my integer benchmark increase to almost 5500 MIPS, which seems wildly out of proportion; the FP benchmark increase was much more modest, just under 2000 MIPS now.

Initially my ignorance and the poor documentation apparently caused me to incorrectly install the new BOINC and SETI client, because all the pre-existing workunits then had errors and failed to complete. I tried renaming the SETI EXE from "411" to "418" as suggested, but when I restarted BOINC it would DELETE the EXE! Eventually I had to leave the EXE and PBD as named.

Of the few workunits that have completed and been granted credit since then, there's a hint of even greater discrepancy between claimed and granted, not less, and the estimated workunit times have actually increased, from about 3:15 - 3:30 to well over 4 hours. Paradoxically the units seem to actually be completing in under 3 hours, about 30 minutes less than the original times. There's certainly not been any 50%-100% improvement like others have claimed.

The system seems to be perfectly stable still, as it was beforehand, but these results are not what I expected after reading the experiences that other people were reporting with this optimized code.

Is there something else I'm overlooking, something that needs to be tweaked? I hope I don't have to abandon the modest overclock to make this optimized stuff work as expected?

Mark

Is there something else I'm overlooking, something that needs to be tweaked?

Probably. There are three files in the optimized SETI application; the exe, the xml, and a pdb. All three of these need to be copied into the correct folder. There is no need (or recommendation) to rename anything, and if properly done, even a result that has already been started will pick up where it left off.

Your computers are hidden, so other than saying the above, there's not much we can tell you. If you will show your computers, then we can at least tell if you have each piece correctly installed once you've done a result with them.

Also, please point us to where the documentation you followed is; we may be able to recommend a different set, or corrections to that one.

I've seen bubbly glowing effusive testimonials about optimized SETI/BOINC software, and in particular CrunchR's variants, but I've now tried those and on my system the results are much more modest, maybe even counterproductive. I'm wondering if there's a tuning or other issue that I can change to have similarly wondrous results.

I was once way down on the optimized stuff. I then, on a lark, tried one of Crunch3r's linux optimized S@H apps and got religion.

My current system uses an AMD Athlon XP 2500+, MSI K7N2G-ILSR motherboard, and 2x512MB Mushkin PC3200 DDR400 RAM modules as dual DDR. I have modestly overclocked the CPU by about 7% using just the FSB pushed from 166/333 to 179/358. The system is also watercooled with a Koolance Exos. The RAM is underclocked with that, and I suspect I could do better by reducing the CPU multiplier and increasing the FSB to 200/400. I would have already tried it, but only the CPU is watercooled right now and the chipset/onboard GPU shows hints of being the weak link; I have a water block for that as well, but need to install it.

Nice system!

After doing my best to understand and follow the very limited instructions, I saw my integer benchmark increase to almost 5500 MIPS, which seems wildly out of proportion; the FP benchmark increase was much more modest, just under 2000 MIPS now.

Now there are two DIFFERENT optimized programs out there. One is an optimized BOINC client. All that does is goose up your benchmark scores so you claim more credit. I am not a fan of this, and don't use them. I do more than one project, and gooseing the benchmarks up on those other projects is considered bad form. The other class are optimized S@H apps. The one on Crunch3r's site rules. My times on my XP1800+ computer on linux went from about 4.5 hours with the stock client to just a hair over 2 hours with the optimized one. I don't know about the windoze optimized S@H app. from Crunch3r, but I have heard that it's gains are similar. I have never tried one on windoze.

Initially my ignorance and the poor documentation apparently caused me to incorrectly install the new BOINC and SETI client, because all the pre-existing workunits then had errors and failed to complete. I tried renaming the SETI EXE from "411" to "418" as suggested, but when I restarted BOINC it would DELETE the EXE! Eventually I had to leave the EXE and PBD as named.

Of the few workunits that have completed and been granted credit since then, there's a hint of even greater discrepancy between claimed and granted, not less, and the estimated workunit times have actually increased, from about 3:15 - 3:30 to well over 4 hours. Paradoxically the units seem to actually be completing in under 3 hours, about 30 minutes less than the original times. There's certainly not been any 50%-100% improvement like others have claimed.

The system seems to be perfectly stable still, as it was beforehand, but these results are not what I expected after reading the experiences that other people were reporting with this optimized code.

Is there something else I'm overlooking, something that needs to be tweaked? I hope I don't have to abandon the modest overclock to make this optimized stuff work as expected?

Mark

I used the instructions in the wiki and adapted them for linux. I only had one minor glitch (it deleted two results that had been downloaded), but went otherwise flawlessly. Maybe these instructions can help you as well.

---

https://youtu.be/iY57ErBkFFE

#Texit

Don't blame me, I voted for Johnson(L) in 2016.

Truth is dangerous... especially when it challenges those in power.

I'm using crunch3r's app and it's been great. Just unzipped it, copied them into the seti directory.

I now do WU's in 33-37 minutes when doing 1 at a time, and about an hour when doing 2 at a time with HT.

p4 3.2GHz HT

---

BM and MK:

I substituted both the BOINC service and SETI client. I'd read (or thought I'd read) that both were needed in order to ensure the best convergence between claimed and granted credit. Substantial discrepancies between my claimed and granted credits was largely what motivated me to try this, not because I was hoping to "crunch more". I was seeing many units where I was being granted much less credit than what was claimed, which seemed to suggest considerable wastefulness or inaccuracy at some point in the process.

I used what few instructions were directly on CrunchR's site, where the downloads reside: http://www.guntec.de/Crunch3r/setix86.html. Had I known about the wiki that MajorKong mentioned - for instance had CrunchR linked to it in an obvious place that I could notice - that might have helped me avoid some of the initial unpleasantness. I guess the proper thing to do, in fact, was to either empty the queue completely first, or perhaps at least leave the "blessed" client files in place, hoping that they'd be used to finish off the pre-existing workunits. Certainly trying to simply rename the new files as the originals didn't fool BOINC, and it retaliated by outright deleting them. I did copy all three of the client files, in any case. Since CrunchR provides the same Windows SSE SETI client for both Pentium III and Athlon XP, that's the one I used.

I did try to reveal my computer right after posting, but apparently it takes time to "propagate". I can see it linked to my profile now, in any case.

Now here's another question: since I did make a complete copy of the BOINC folder before I experimented, if I restored it outright (or perhaps even in part) could I get those errored workunits to restart and complete? It's probably not a big issue, since it's not like time was wasted on every one of them; only one was in progress, the others were maids in waiting.

My concern is narrowing the claimed and granted discrepancy, and determining if these optimized apps are part or all of the solution to that problem. I have no interest in gaming the system... I just want my PC to get credit for the work it actually did.

Mark

Ok, Mark I looked at your credit and it appears that you are getting some credit that you claim, but most are just below that claim by a few points. As you can see, by the WUs listed below, you will never get your claimed credit, if you are the high or the low score, as the system throws out the high and low and give all the middle score....

186944598 2020779 30 Dec 2005 20:06:48 UTC 2 Jan 2006 22:59:39 UTC Over Success Done 2,388.36 4.03 30.09
186944599 2009827 30 Dec 2005 20:06:49 UTC 13 Jan 2006 20:06:49 UTC In Progress Unknown New --- --- ---
186944600 1104317 30 Dec 2005 20:06:49 UTC 31 Dec 2005 4:55:47 UTC Over Success Done 10,630.23 30.09 30.09
186944601 1753034 30 Dec 2005 20:06:49 UTC 31 Dec 2005 20:10:04 UTC Over Success Done 11,451.30 30.54 30.09


So increasing your score will not help you....

---

And the beat goes on
Sonny and Cher

BOINC Wiki

My current system uses an AMD Athlon XP 2500+, MSI K7N2G-ILSR motherboard, and 2x512MB Mushkin PC3200 DDR400 RAM modules as dual DDR. I have modestly overclocked the CPU by about 7% using just the FSB pushed from 166/333 to 179/358. The system is also watercooled with a Koolance Exos. The RAM is underclocked with that, and I suspect I could do better by reducing the CPU multiplier and increasing the FSB to 200/400. I would have already tried it, but only the CPU is watercooled right now and the chipset/onboard GPU shows hints of being the weak link; I have a water block for that as well, but need to install it.

I have found that using different FSB on AMD chips causes problems.
You might try either 166/166 or 179/179. This should stabilize your system and bring it more in line with claimed credits.

---

My concern is narrowing the claimed and granted discrepancy, and determining if these optimized apps are part or all of the solution to that problem. I have no interest in gaming the system... I just want my PC to get credit for the work it actually did.

It will, the whole point to the averaging system was to remove the error that was expected to occur. The problem not anticipated was the wide discrepancies between the various systems.

There is not a lot of point in trying to "narrow" the gap ... the averaging makes this futile. Worse, trying to "fix" things does not make any difference in the long run. The current "truth" is that there is not a "correct" amount of credit. The next generation (as others have said) will try to narrow the gap between the various claims by counting operations performed.

Even so, there will be differences. We hope that the differences will be down in the 5% area rather than the 400% you can see now. However, I am not going to be sold that this will be true until we see the system in wide-spread use. Even then, there will still be problems as some are still using older BOINC Client Software and so will be returning claims with the older system. But, we will be able to look at hundreds of returns instead of the 10s of returns we are looking at from the Beta test.

If the variations are still too large there are some more advanced concepts that could be tried to to improve the system. And, *I* think, in time we will implement if only because they make sense to make the whole process more resilient and resistant to tampering. But, as credit, important as it is, is a side show; well, the changes will be slow in coming ...

You can read up on it in the Wiiki, if you want a historical and comprehensive critique you can search on the key word calibration and there is a fairly long paper in there with links to much of the historical discussion about the system and how we got here ....

---

My current system uses an AMD Athlon XP 2500+, MSI K7N2G-ILSR motherboard, and 2x512MB Mushkin PC3200 DDR400 RAM modules as dual DDR. I have modestly overclocked the CPU by about 7% using just the FSB pushed from 166/333 to 179/358. The system is also watercooled with a Koolance Exos. The RAM is underclocked with that, and I suspect I could do better by reducing the CPU multiplier and increasing the FSB to 200/400. I would have already tried it, but only the CPU is watercooled right now and the chipset/onboard GPU shows hints of being the weak link; I have a water block for that as well, but need to install it.

I have found that using different FSB on AMD chips causes problems.
You might try either 166/166 or 179/179. This should stabilize your system and bring it more in line with claimed credits.

I think you misunderstood what I meant by the slashed pairs of numbers; did you think that the first number was for CPU and second one for RAM? That's not what I meant... the actual bus clock on this system is doubled to create the FSB value, so I was simply mentioning both. The RAM is using a 1-to-1 ratio from the bus clock, so both it and the CPU are clocked the same: 179MHz bus clock, 358MHz FSB. Is that what you meant, to suggest that RAM should run at the same "speed" as the CPU?

Mark

Ok, Mark I looked at your credit and it appears that you are getting some credit that you claim, but most are just below that claim by a few points. As you can see, by the WUs listed below, you will never get your claimed credit, if you are the high or the low score, as the system throws out the high and low and give all the middle score....

186944598 2020779 30 Dec 2005 20:06:48 UTC 2 Jan 2006 22:59:39 UTC Over Success Done 2,388.36 4.03 30.09
186944599 2009827 30 Dec 2005 20:06:49 UTC 13 Jan 2006 20:06:49 UTC In Progress Unknown New --- --- ---
186944600 1104317 30 Dec 2005 20:06:49 UTC 31 Dec 2005 4:55:47 UTC Over Success Done 10,630.23 30.09 30.09
186944601 1753034 30 Dec 2005 20:06:49 UTC 31 Dec 2005 20:10:04 UTC Over Success Done 11,451.30 30.54 30.09


So increasing your score will not help you....

Jim:

What freaked me out was one of the earliest results after the client switch: 85.26 claimed and 17.83 granted! I had never seen that degree of discrepancy with the standard client and BOINC. There were discrepancies, sure, and I'd thought I could narrow them with this approach, but they were rarely more than ten points divergent.

As you pointed out, the most recent ones granted (since I posted last night) are less extreme than that early example. Then again, as Paul suggests in his post, my quest to narrow the gap may not be as constructive as I thought.

The "optimized" client does seem to be helping my system complete the same work in a bit less time, in any case, so that may be a good thing as long as it's not achieved through cheating or "creative accounting". Would the conservative consensus be that keeping the optimized client is a good thing (if it allows more work to get done), but that the optimized BOINC is dodgey and not a good thing?

Mark

Mark, looking at your latest results, you have correctly installed and are running both the optimized SETI application and the optimized BOINC client.

I wouldn't worry about the WUs that were "lost" - they'll automatically be reissued to someone else, and the "recovery process" is so difficult, it's really not worth the effort.

The "optimized" client does seem to be helping my system complete the same work in a bit less time, in any case, so that may be a good thing as long as it's not achieved through cheating or "creative accounting". Would the conservative consensus be that keeping the optimized client is a good thing (if it allows more work to get done), but that the optimized BOINC is dodgey and not a good thing?

You're using the term exactly backwards. The optimized "client" _IS_ the BOINC part, and only raises your claimed credit. The optimized "application" is the SETI part that makes you crunch faster.

BOINC = client
SETI = application

If you are running SETI only, or have something like Einstein as a backup project with less than a 50% resource share (highly recommended, btw), then I would leave everything exactly as you have it.

If you are running other projects that prefer you not run an optimized BOINC client, such as Rosetta, then it wouldn't hurt your credits here much, if at all, to go back to the "standard" version.

What freaked me out was one of the earliest results after the client switch: 85.26 claimed and 17.83 granted! I had never seen that degree of discrepancy with the standard client and BOINC. There were discrepancies, sure, and I'd thought I could narrow them with this approach, but they were rarely more than ten points divergent.

That unit and the adjacent one with a 51.10 claim were both crunched before your changeover but reported after. That is, the claim was based on multiplying the new benchmark operations/second by the seconds expended by the old application. That fully explains the 51.10 claim, but the 85.26 claim was caused by a crunch time nearly double what it should have been. Other hosts which did the same unit had normal times. Probably what happened was 4.18 restarted the work; that's a rare but not unknown occurrence.

The "optimized" client does seem to be helping my system complete the same work in a bit less time, in any case, so that may be a good thing as long as it's not achieved through cheating or "creative accounting". Would the conservative consensus be that keeping the optimized client is a good thing (if it allows more work to get done), but that the optimized BOINC is dodgey and not a good thing?

Mark

My impression is that about equal numbers favor using/not using an optimized BOINC client when using an optimized SETI application. That's good, it tends to make the average claim about right.

Only getting "a bit less time" with Crunch3r's SETI app is definitely unusual. Systems similar to yours got about a 30% reduction in crunch times from TMR's YAOSCW-K-r8.1 as reported on the reference comparison page. You might want to try that instead, download here.

                                                    Joe

<snip>

Only getting "a bit less time" with Crunch3r's SETI app is definitely unusual. Systems similar to yours got about a 30% reduction in crunch times from TMR's YAOSCW-K-r8.1 as reported on the reference comparison page. You might want to try that instead, download here.

                                                    Joe

Not only is "a bit less time" unusual but every 'completed' result of his, using Crunch3r's SETI app has "No heartbeat from core client for 31 sec - exiting" in the stderr_txt text. Also, the text line showing 'cache calculated' should be reporting it as 53 times (all of mine do, AMD & Intel). Mark's seem to be variable. Something is not right in his PC. Memory, perhaps??

kev

---

kev

X2 4400+,4200+ @2.75GHz, XP1800+ @1.65GHz, P4 @1.6GHz

My current system uses an AMD Athlon XP 2500+, MSI K7N2G-ILSR motherboard, and 2x512MB Mushkin PC3200 DDR400 RAM modules as dual DDR. I have modestly overclocked the CPU by about 7% using just the FSB pushed from 166/333 to 179/358. The system is also watercooled with a Koolance Exos. The RAM is underclocked with that, and I suspect I could do better by reducing the CPU multiplier and increasing the FSB to 200/400. I would have already tried it, but only the CPU is watercooled right now and the chipset/onboard GPU shows hints of being the weak link; I have a water block for that as well, but need to install it.

Doesn't your motherboard have AGP clock lock in BIOS? If so, just set it to stay at 66MHz and you can eliminate it as a weak link in your OC efforts.

Also, what are your RAM's timings? Tight timings often make more of a performance difference than high fsb (to a point, of course). For example, I have found that simply going from CAS 2.5 to 2 is the equivalent of a 10MHz fsb bump. Also, in two nearly identical rigs I currently have running where the only difference is the RAM the one with tighter timings (6-2-2-2) completes units an average of 10-15 minutes faster, about 1:05, than the other does with looser timings (8-4-4-2), about 1:15 - 1:20.


Good luck

P.S. Compare "Second" and "Third" in my setup. "Second" reports as a 3200 but it's really a 2800.

---

Without love, breath is just a clock ... ticking.
Equilibrium

My xp2500+ is doing work in half the time of yours Mark.

Motherboard K7N2 Delta
Memory PC3200 OCZ400512ELDC-K Dual Channel

Core Speed 2105 Mhz
Multiplier x 10.5
FSB 200.5 Mhz
Bus Speed 401.0 Mhz
Timings of 2 3 2 6

This is with air cooling too!
CPU Temp. 51c in a very warm house (my wife likes it way to hot, damn menopause)

Hope this info helps you get your system working better :)

---

98SE XP2500+ @ 2.1 GHz Boinc v5.8.8

And God said"Let there be light."But then the program crashed because he was trying to access the 'light' property of a NULL universe pointer.

Bill Michael said:

You're using the term exactly backwards. The optimized "client" _IS_ the BOINC part, and only raises your claimed credit. The optimized "application" is the SETI part that makes you crunch faster.

BOINC = client
SETI = application

Ooops. Is that a sign of dyslexia? :-)

Josef Segur said:

Only getting "a bit less time" with Crunch3r's SETI app is definitely unusual. Systems similar to yours got about a 30% reduction in crunch times from TMR's YAOSCW-K-r8.1 as reported on the reference comparison page. You might want to try that instead, download here.

The closest analog on that page is a HEAVILY overclocked XP 2500+ system using a similar MSI motherboard. I have no intention of pushing this one that far/hard, particularly because my new Athlon64 system is almost ready to replace this one as my primary system. I haven't decided yet whether I'm even keeping this one after that. The new Athlon64 system will not be overclocked, because the Exos system is not usable with it at all unless I want to spend bucks on a new block for the CPU (and Koolance blocks cost a relative fortune and have gotten much worse since I bought the Exos).

After looking at that reference system's numbers, though, I've concluded that I'm really not very far behind the curve if at all. My very latest results were scary-weird fast and scary-weird short, though:

191589754 Success Done 4,753.72 20.52 pending
191411384 Success Done 5,357.25 23.13 pending
191411367 Success Done 5,438.89 23.48 pending
191411362 Success Done 5,315.83 22.95 pending
191411358 Success Done 5,380.44 23.23 pending
191411236 Success Done 5,313.66 22.94 pending

They completed in about half the time of the previous few, but with only half the claimed credit. Hmmmm....

Kev1701e said:

Not only is "a bit less time" unusual but every 'completed' result of his, using Crunch3r's SETI app has "No heartbeat from core client for 31 sec - exiting" in the stderr_txt text. Also, the text line showing 'cache calculated' should be reporting it as 53 times (all of mine do, AMD & Intel). Mark's seem to be variable. Something is not right in his PC. Memory, perhaps??

Is that an actual error condition? Do you know what it means or what conditions can cause it? If there's anything "not right" right now, it's the weird 358MHz FSB, which perhaps the RAM or something else doesn't like. The RAM isn't even overclocked at that (it's Mushkin PC3200 DDR400). I hope to fix that soon with a 400MHz FSB and a lower CPU multiplier.

Before I can worry about this, I have to know what the ramifications and possible causes are.

Jim said:

Doesn't your motherboard have AGP clock lock in BIOS? If so, just set it to stay at 66MHz and you can eliminate it as a weak link in your OC efforts.

Also, what are your RAM's timings? Tight timings often make more of a performance difference than high fsb (to a point, of course). For example, I have found that simply going from CAS 2.5 to 2 is the equivalent of a 10MHz fsb bump. Also, in two nearly identical rigs I currently have running where the only difference is the RAM the one with tighter timings (6-2-2-2) completes units an average of 10-15 minutes faster, about 1:05, than the other does with looser timings (8-4-4-2), about 1:15 - 1:20.

I think I already have the AGP bus locked at 66MHz, but I will check. My concern isn't just the integrated GPU, it's the entire Northbridge. Right now the CPU temp is 25C, while the chipset is at 39C! You see the problem, I assume? That's likely the reason why my attempt to overclock it further with a higher FSB failed. When I have a water block straddling the sucker I may do better. I'm just not looking forward to having to cut tubing and drain and refill the Exos.

My RAM is Mushkin DDR400 CAS 2, and the timing is now at 2-2-2-5, though if I get the FSB up to 400 I expect that to change a bit, perhaps 2-2-2-6 or 2-3-3-6.

Steve Cressman said:

This is with air cooling too! CPU Temp. 51c in a very warm house....

Dude...! I hope you keep a fire extinguisher handy. My CPU temp right now is 25C, LESS THAN HALF of yours, with SETI running full tilt, and I keep a "warm house" at 75F myself (I'm such a temperature woosie). That warm house (high ambient temps) is why I got the Exos in the first place, to deal with very poor cooling in the summer, though I don't so much need it for that now. I don't really need to overclock, either, but I haven't tried it since I overclocked NEC V-something-or-other chips and IBM AT systems in the Eighties, so I figgered I'm about due for a little experimentation.

Mark

---

Mark

Is there something else I'm overlooking, something that needs to be tweaked?

Probably. There are three files in the optimized SETI application; the exe, the
xml, and a pdb. All three of these need to be copied into the correct folder. There is no need (or recommendation) to rename anything, and if properly done, even a result that has already been started will pick up where it left off.

Also, please point us to where the documentation you followed is; we may be able to recommend a different set, or corrections to that one.

Why is a ".pdb" file required ?? Because its a data base file What's in it and how is it used by the application.???

---

<snippage>

After looking at that reference system's numbers, though, I've concluded that I'm really not very far behind the curve if at all. My very latest results were scary-weird fast and scary-weird short, though:

191589754 Success Done 4,753.72 20.52 pending
191411384 Success Done 5,357.25 23.13 pending
191411367 Success Done 5,438.89 23.48 pending
191411362 Success Done 5,315.83 22.95 pending
191411358 Success Done 5,380.44 23.23 pending
191411236 Success Done 5,313.66 22.94 pending

They completed in about half the time of the previous few, but with only half the claimed credit. Hmmmm....

Your runtimes are *much* better now and appear to be in the normal range. Credit claims can be adjusted by using an 'optimised' BOINC client.

Kev1701e said:

Not only is "a bit less time" unusual but every 'completed' result of his, using Crunch3r's SETI app has "No heartbeat from core client for 31 sec - exiting" in the stderr_txt text. Also, the text line showing 'cache calculated' should be reporting it as 53 times (all of mine do, AMD & Intel). Mark's seem to be variable. Something is not right in his PC. Memory, perhaps??

Is that an actual error condition? Do you know what it means or what conditions can cause it? If there's anything "not right" right now, it's the weird 358MHz FSB, which perhaps the RAM or something else doesn't like. The RAM isn't even overclocked at that (it's Mushkin PC3200 DDR400). I hope to fix that soon with a 400MHz FSB and a lower CPU multiplier.

Before I can worry about this, I have to know what the ramifications and possible causes are.

The Wiki says that the "no heartbeat" is an error where BOINC and SETI aren't talking to each other. As to why this was happening, I have no clue but it seems the issue has gone away. Perhaps whatever adjustments you have made to your system has fixed it.

As a side note, you shouldn't need your Exos system to o/c your A64. My Winchester 3000+ is at 2.3GHz on air(42C). A64s run much cooler than XPs.

kev

---

kev

X2 4400+,4200+ @2.75GHz, XP1800+ @1.65GHz, P4 @1.6GHz

<snippage>

They completed in about half the time of the previous few, but with only half the claimed credit. Hmmmm....

Your runtimes are *much* better now and appear to be in the normal range. Credit claims can be adjusted by using an 'optimised' BOINC client.

Kev1701e said:

Not only is "a bit less time" unusual but every 'completed' result of his, using Crunch3r's SETI app has "No heartbeat from core client for 31 sec - exiting" in the stderr_txt text. Also, the text line showing 'cache calculated' should be reporting it as 53 times (all of mine do, AMD & Intel). Mark's seem to be variable. Something is not right in his PC. Memory, perhaps??

Is that an actual error condition? Do you know what it means or what conditions can cause it? If there's anything "not right" right now, it's the weird 358MHz FSB, which perhaps the RAM or something else doesn't like. The RAM isn't even overclocked at that (it's Mushkin PC3200 DDR400). I hope to fix that soon with a 400MHz FSB and a lower CPU multiplier.

Before I can worry about this, I have to know what the ramifications and possible causes are.

The Wiki says that the "no heartbeat" is an error where BOINC and SETI aren't talking to each other. As to why this was happening, I have no clue but it seems the issue has gone away. Perhaps whatever adjustments you have made to your system has fixed it.

As a side note, you shouldn't need your Exos system to o/c your A64. My Winchester 3000+ is at 2.3GHz on air(42C). A64s run much cooler than XPs.

kev

Kev:

You know what else makes a huge difference, and something over which I have no immediate direct control? The RDCF, Result Duration Correction Factor! When I posted that last night, this system's RDCF was down to 0.64, when it had earlier been much closer to 1. As of right now, it's 0.49! It's DROPPING, in other words, and things look to be improving and stabilizing at the same time. It's the SETI/BOINC backend adjusting it gradually in response to the results I return, clearly. Apparently changing the environment causes teething pains that need time to accomodate.

Also, the last few results with granted credit, four of them, were granted EXACTLY the claimed credit, down to the last hundredth. If that's really a "movement" and the pattern continues, that will be a vast improvement. Many of my earlier results had noticeable discrepancy in claimed and granted, usually with granted being lower.

I finally found the BOINC Wiki and religion with it :-) and read up on RDCF and the error and much else. I'm not ready to conclude the missed heartbeat is a serious problem, but whatever is causing it seems to have been present before I started using the optimized app and client (I went back to the earliest displayed result, and it had five missed heartbeats). It might be due to my using BOINC as a service and only running Manager as needed, not continuously.

Right now my estimated and actual CPU times are below 2 hours, so I think the drop in the RDCF for this computer is making some difference.

I also changed some of the BOINC settings. Virtual memory usage was limited to 50% and I increased it to 90%, and reduced the disk-write interval from 60 to 900 seconds. I got bit by the latest outage and S@H went for a day without anything to do, so I also bumped the connection interval up to two days.

---

Mark