Just to add to my times in my earlier post I benched Crunch3r's newest and this is the results on my P3:

crunch3r
setiathome_4.07.3-P3-fftw3-static-cache-linux-gnu

real 273m17.107s
user 269m47.430s
sys 1m7.730s
wu_cpu_time=17224.400000

My GCC-4/FFTW3 builds are still giving weak similarity. Not sure why and I haven't had time to play with it yet to try and figure it out. Obviously they're built from the same source (Harold's) that gives strong similarity for him, so it's definately not Harold's source :)

Ned, what BOINC source are you compiling against? i haven't had success with GCC/FFTW on any of the caching sources yet.

have you changed the optimization flags at all?

My GCC-4/FFTW3 builds are still giving weak similarity. Not sure why and I haven't had time to play with it yet to try and figure it out. Obviously they're built from the same source (Harold's) that gives strong similarity for him, so it's definately not Harold's source :)

Ned, what BOINC source are you compiling against? i haven't had success with GCC/FFTW on any of the caching sources yet.

have you changed the optimization flags at all?

You need the BOINC 4.45 source to get i working.

---

Join BOINC United now!

benchmark:

my-naparst-r3.1-no-prec
4602.180384
my-naparst-r3-no-prec
4903.025649
my-naparst-r3.1-prec
4903.058644

my-naparst-r3.1-no-prec
4603.058251
my-naparst-r3-no-prec
4602.448343
my-naparst-r3.1-prec
4903.244615

./rescmp/rescmp result_unit.sah my-naparst-r3.1-no-prec/result.sah
Result: these are strongly similar.
./rescmp/rescmp result_unit.sah my-naparst-r3.1-prec/result.sah
Result: these are strongly similar.
./rescmp/rescmp result_unit.sah my-naparst-r3-no-prec/result.sah
Result: these are weakly similar.

So, no-prec will not get weak similar, and also get more performance.

---

So, no-prec will not get weak similar, and also get more performance.

Good work. I wonder if that is true for other workunits too.
Do you want to try a few other workunits to see if the strong similarity
is robust?

---

Harold Naparst

This workunit failed to validate, running the optimized linux client on a stock SuSE 10.0 install.

This is the first failure to validate I've had, posted just in case someone needs to know. (There's one other client error listed for the computer, but that's the unit started with the standard science app that errored out when I switched to the optimized app.) Darn good work on the optimization!

Cheers,

Brian

---

If you think education is expensive, try ignorance.

This is the first failure to validate I've had, posted just in case someone needs to know.

Well, it is understandable that it failed to validate because the
cruncher segfaulted at the end of the workunit. Please upgrade to r3.1
and let me know if this happens again. There was a bug that I thought I had
fixed, but maybe not....

---

Harold Naparst

Well, it is understandable that it failed to validate because the
cruncher segfaulted at the end of the workunit. Please upgrade to r3.1
and let me know if this happens again. There was a bug that I thought I had
fixed, but maybe not....

OK, I just set S@H to "no new work" so the work queue can drain. Once I've upgraded I'll let you know if it happens again. Thanks!

---

If you think education is expensive, try ignorance.

Well, it is understandable that it failed to validate because the
cruncher segfaulted at the end of the workunit. Please upgrade to r3.1
and let me know if this happens again. There was a bug that I thought I had
fixed, but maybe not....

OK, I just set S@H to "no new work" so the work queue can drain. Once I've upgraded I'll let you know if it happens again. Thanks!

You know, I don't think you have to do this.
I just stop the boinc process, copy the new cruncher and app_info.xml
file into the setiathome.berkeley.edu directory, and restart boinc.
On Fedora, it goes like this:

service boinc stop
cd ~boinc/projects/setiathome.berkeley.edu
tar xzvf naparst-blah.tgz
service boinc start

---

Harold Naparst

My GCC-4/FFTW3 builds are still giving weak similarity. Not sure why and I haven't had time to play with it yet to try and figure it out. Obviously they're built from the same source (Harold's) that gives strong similarity for him, so it's definately not Harold's source :)

Ned, what BOINC source are you compiling against? i haven't had success with GCC/FFTW on any of the caching sources yet.

have you changed the optimization flags at all?

I'm using v4.43; 25 May (or 4.45; 6 June), I'm not absolutely sure. I can let you know for sure when I get home this evening.

I'm still using my old set of flags from my older clients still on my website (the clients, not the flags!). I know these work.

Crunch3r has been working on an updated set, but I had a few problems when trying to build with them (might have been totally unrelated) - I couldn't get anything to compile so went back to what I knew worked. I still haven't had time to retest Crunch3r's new flags, but I must get around to it soon (but Harold keeps giving us new sources!)

If you need any help, don't be afraid to drop me an e-mail - be glad to help where I can :)

Ned

---

*** My Guide to Compiling Optimised BOINC and SETI Clients ***
*** Download Optimised BOINC and SETI Clients for Linux Here ***

OK, I just set S@H to "no new work" so the work queue can drain.

You know, I don't think you have to do this.
I just stop the boinc process, copy the new cruncher and app_info.xml
file into the setiathome.berkeley.edu directory, and restart boinc.

OK, I'll give this a try when I get home from work. I just didn't want to lose a lot of queued-up work, but if it's as easy as dropping in a new app and restarting, I'll do that. Thanks!

---

If you think education is expensive, try ignorance.

You know, I don't think you have to do this.
I just stop the boinc process, copy the new cruncher and app_info.xml
file into the setiathome.berkeley.edu directory, and restart boinc.

OK, I'll give this a try when I get home from work. I just didn't want to lose a lot of queued-up work, but if it's as easy as dropping in a new app and restarting, I'll do that. Thanks!

whoa, be careful. if the version number listed in app_info.xml changes, you will lose all the WU's in your directory, finished or not. if the number stays the same, however, the worst that happens is you get one unit that doesnt validate because it was partially crunched by two different clients.

all of harold's downloads so far have used the same version (i believe) but always check it because in addition to losing work units, they report as client errors and are awarded 0 credit. the 0's average into your RAC and bring your score way down.

I just didn't want to lose a lot of queued-up work, but if it's as easy as dropping in a new app and restarting, I'll do that. Thanks!

whoa, be careful. if the version number listed in app_info.xml changes, you will lose all the WU's in your directory, finished or not. if the number stays the same, however, the worst that happens is you get one unit that doesnt validate because it was partially crunched by two different clients.

That's why I was considering letting everything finish with the client I've got, just in case. I'll check the version listing; if it's the same in the 2 versions, I'll go ahead & move to the newer client, otherwise I'll finish what I've got first, so there's only 1 or 2 work units at risk.

---

If you think education is expensive, try ignorance.

I just didn't want to lose a lot of queued-up work, but if it's as easy as dropping in a new app and restarting, I'll do that. Thanks!

whoa, be careful. if the version number listed in app_info.xml changes, you will lose all the WU's in your directory, finished or not. if the number stays the same, however, the worst that happens is you get one unit that doesnt validate because it was partially crunched by two different clients.

My understanding (after tinkering often with app_info) is that you can define one science app for multiple cases. This is the app_info that I used to upgrade from Crunchr's latest build:

<app_info>
    <app>
        <name>setiathome</name>
    </app>
    <file_info>
        <name>setiathome_4.07.3-athlon-xp-fftw3-static-pc-linux-gnu</name>
        <executable/>
    </file_info>
    <app_version>
        <app_name>setiathome</app_name>
        <version_num>470</version_num>
        <file_ref>
            <file_name>setiathome_4.07.3-athlon-xp-fftw3-static-pc-linux-gnu</file_name>
            <main_program/>
        </file_ref>
    </app_version>
</app_info> 
<app_info>
    <app>
        <name>setiathome</name>
    </app>
    <file_info>
        <name>setiathome-4.07.3d-athlon-xp-static-pc-linux-gnu</file_name>
        <executable/>
    </file_info>
    <app_version>
        <app_name>setiathome</app_name>
        <version_num>470</version_num>
        <file_ref>
            <file_name>setiathome_4.07.3d-athlon-xp-fftw3-static-pc-linux-gnu</file_name>
            <main_program/>
        </file_ref>
    </app_version>
</app_info>

Before I was running (I think) Ned's build of Naparst-3.0 optimisation. In order to keep track I had called that 4.07.03d (variant #4). When the new one got out a day after the previous I decided to no longer give it a unique filename, but just stick to the name as distributed, i.e. ... 4.07.3.... I believe that above app_info tells boinc that both WU's that are being 'crunched' with 4.07.03d and 4.07.3 should be crunched by 4.07.3. I stopped boinc, edited app_info as above and then restarted booinc (service boinc start). The WU which was at 30% continued as before (and has validated in the mean time).

Now the only thing that we need help with is stderr_txt: naparst-2.75, -3.0, -3.1 equate to 2s, 2.05s, 2.07s, REV 107, 121, 142 and a name 4.07.3 or 4.7.

Ned/Crunchr/Harald et al: I also see same speed with 3.1, ~5400 s (2 results so far).

---

Well since running these optimized clients my credit has suffered somewhat. Does anyone know where to get a optimized 5.x.x CC for a P3 platform for Linux?

Well since running these optimized clients my credit has suffered somewhat. Does anyone know where to get a optimized 5.x.x CC for a P3 platform for Linux?

Starting a new thread. http://setiathome.berkeley.edu/forum_thread.php?id=21833

---

Just upgraded to naparst r3.1, went smoothly, no WU's lost. If I get any further failure-to-validate, I'll post a link here.

---

If you think education is expensive, try ignorance.

Disregard previous message... After upgrading to r3.1, things went smoothly, another 5 WU's finished, the app_info in the xml file is the same for r3.1 as for the 3.0 client...but then this happened:

exit with error code 0x2
exit with error code 0x2
exit with error code 0x2
exit with error code 0x2
exit with error code 0x2
exit with error code 0x2

Looking under the "work" tab, it does indeed look like many many work units bit the big one.

The SETI server's currently not talking to me (quota exceeded), so BOINC has switched over to Einstein (the 'backup' project).

So is this a side effect of a bungled app upgrade on my part, or do I need to be concerned about my computer? Is a re-install or detach/reattach in order?

Edit: As long as I've lost all the SETI work units, I'm going to wipe the app_info.xml and the application, and do a clean-reinstall.

Another edit: If anyone wants to view all the carnage... here it is.

---

If you think education is expensive, try ignorance.

So, no-prec will not get weak similar, and also get more performance.

Good work. I wonder if that is true for other workunits too.
Do you want to try a few other workunits to see if the strong similarity
is robust?

23my04aa.20947.21680.778410.158
23my04aa.20947.23218.567336.243

./rescmp my-naparst-r3.1-no-prec/result.sah my-naparst-r3.1-prec/result.sah
Result: these are strongly similar.

I tested these two small WUs, and they are both strongly similar.
Of course, no-prec is faster than prec about 6%.

---

./rescmp my-naparst-r3.1-no-prec/result.sah my-naparst-r3.1-prec/result.sah
Result: these are strongly similar.

I tested these two small WUs, and they are both strongly similar.
Of course, no-prec is faster than prec about 6%.

Well, if you feel strongly (heh-heh) about this, I'll use no-prec-div and
no-prec-sqrt with the next client. Are you confident about this result?

---

Harold Naparst