Another possibility using the linking methodology would be to use absolutely identical site structures (as we're already very similar anyway) and have links in the left hand navigation panel for "AMD Clients", "Intel Clients", "Alpha Clients" etc that are direct links to each others sites for those pages, rather than locally mirrored pages. So, for example, if a visitor to my site clicked on the "Alpha Clients" navigation panel link they'd jump straight to Crunch3r's site without even knowing it, and similarly then clicked on the Intel navigation panel link they'd jump on to Harolds site - that way each person only needs maintain the page for their own individual clients and the rest of the site layout is just an exact copy on each server - no mirroring needed.

... Ahh. Hmm. Don't know what to say here. How about a change of topic?

What would you think would be an appropriate maximum amount of memory
for the caches to use? Although Hans might disagree, (and I might be wrong)
my explorations seem to show that it is important to have more than 8MB cache. The chances of finding cached data are much higher if the cache is larger. Would you think that a cache of 160 MB is OK? Or is that still too large?

... just built a static version for Athlon XP:

http://www.pperry.f2s.com/files/setiathome-ned-v3.0.tar.gz

It's experimental - I've NOT tested it - so use at your own risk. I'm not 100% sure it's totally static, but it runs on my boxes OK on the very quick 30 second test I did. ...

PS - Please could you let me know if it spawns 3 setiathome processes like Crunch3r's client does, or just the one - thatnks.

.boinc/projects/setiathome.berkeley.edu/app_info.xml
<app_info>
    <app>
        <name>setiathome</name>
    </app>
    <file_info>
        <name>setiathome_4.07.3b_athlon-xp-fftw3-static-pc-linux-gnu</name>
        <executable/>
    </file_info>
    <app_version>
        <app_name>setiathome</app_name>
        <version_num>407</version_num>
        <file_ref>
            <file_name>setiathome_4.07.3b_athlon-xp-fftw3-static-pc-linux-gnu</file_name>
            <main_program/>
        </file_ref>
    </app_version>
    <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.3b_athlon-xp-fftw3-static-pc-linux-gnu</file_name>
            <main_program/>
        </file_ref>
    </app_version>
    <app>
        <name>setiathome</name>
    </app>
    <file_info>
        <name>setiathome_4.02_i686-pc-linux-gnu</name>
        <executable/>
    </file_info>
    <app_version>
        <app_name>setiathome</app_name>
        <version_num>402</version_num>
        <file_ref>
            <file_name>setiathome_4.07.3b_athlon-xp-fftw3-static-pc-linux-gnu</file_name>
            <main_program/>
        </file_ref>
    </app_version>
</app_info>

.boinc/projects/setiathome.berkeley.edu/app_info.xml
<app_info>
    <app>
        <name>setiathome</name>
    </app>
    <file_info>
        <name>setiathome-4.07.athlon-xp-static-pc-linux-gnu</name>
        <executable/>
    </file_info>
</app_info>

I've mentioned elsewhere that anything up to 256MB total resources for boinc is acceptable for this system (mine). Those with less memory are going to be squealing a little though so it comes down to a case of using the minimum sized cache that is essential for the speedup. Another 100MB for a 0.1% improvement can be forgone. Or is trig cache size vs speedup a linear relation?

Needless to say, I'm not going to gut my Windows machine for Linux

What would you think would be an appropriate maximum amount of memory
for the caches to use? Although Hans might disagree, (and I might be wrong)
my explorations seem to show that it is important to have more than 8MB cache. The chances of finding cached data are much higher if the cache is larger. Would you think that a cache of 160 MB is OK? Or is that still too large?

... Do I guess right that I'd better trim that down to just:

.boinc/projects/setiathome.berkeley.edu/app_info.xml
<app_info>
    <app>
        <name>setiathome</name>
    </app>
    <file_info>
        <name>setiathome-4.07.athlon-xp-static-pc-linux-gnu</name>
        <executable/>
    </file_info>
</app_info>

Or must there be at least one app_version in there?

(And "[code]" doesn't seem to do much for formatting that lot!)

@spacemeat --> Portage has icc-9 and gcc-4.0.2, but they don't have
IPP. Anyway, that shouldn't stop you. It is a very simple matter
to install them and compile with the appropriate flags. The instructions
are on my web site: http://naparst.name/sources.htm
Have fun, and let us know if GCC/FFTW is faster than ICC/IPP.

@spacemeat --> Portage has icc-9 and gcc-4.0.2, but they don't have
IPP. Anyway, that shouldn't stop you. It is a very simple matter
to install them and compile with the appropriate flags. The instructions
are on my web site: http://naparst.name/sources.htm
Have fun, and let us know if GCC/FFTW is faster than ICC/IPP.

how could i forget to check experimental ebuilds...?

ill give it a shot on my (somewhat) faster P3 and see how it compares. i might even give it a shot on K6 which is usually not compatible with i686. maybe even the sparc if i'm crazy...

Warning: It is somewhat difficult to install IPP under Gentoo.
You will have to be resourceful. I recommend becoming familiar
with rpm2cpio and cpio. If you want things to go very smoothly,
install CentOS 3.5 on a designated development machine.

I just had a look at the Cygwin site,
but it looks like you have to compile everything from source, including libraries.
This makes it impossible to use intel's compiler if I'm not wrong.

A better use could be learing about various OSes without having to actually install them. They have just recently released a "Player" that is beta, but looks to be interesting if you don't want to pay for the full product. You could then load up pre-configured images and try anything from Mac to Suse to Solaris...

Warning: It is somewhat difficult to install IPP under Gentoo.
You will have to be resourceful. I recommend becoming familiar
with rpm2cpio and cpio. If you want things to go very smoothly,
install CentOS 3.5 on a designated development machine.

first thing i want to do is upgrade GCC and see what the difference is between i586/i686/SSE versions of caching FFTW3 seti clients compiled and linked on the same pc. that will take more than a weekend on the hardware i have available.

Welcome to the team!! We need all the help we can get.

there is a chance a new gentoo bug can be made for these caching sources. the 'sse' flag in USE sets both --enable-float and --enable-sse in the fftw ebuild so a 'fftw' USE flag in a seti-cache ebuild would make easily buildable linked clients for gentoo users.

Also, for amd64, I can't get fftw to use sse at all.
I've submitted a bugzilla report on Gentoo for this.

harold, is your boinc source altered for ipp? i am seeing a call for mathimf.h when gcc gets to the benchmark code.