The applications are the same as for beta 4.35, i.e.

ap_graphics_4.35_i686-pc-linux-gnu
ap_graphics_4.35_windows_intelx86.exe
ap_graphics_4.35_x86_64-pc-linux-gnu
astropulse_4.35_AUTHORS
astropulse_4.35_COPYING
astropulse_4.35_COPYRIGHT
astropulse_4.35_i686-pc-linux-gnu
astropulse_4.35_windows_intelx86.exe
astropulse_4.35_x86_64-pc-linux-gnu

OK, let's block those out:

[Windows]
astropulse_4.35_windows_intelx86.exe
ap_graphics_4.35_windows_intelx86.exe
libfftw3f-3-1-1a_upx.dll

[Linux_32]
astropulse_4.35_i686-pc-linux-gnu
ap_graphics_4.35_i686-pc-linux-gnu

[Linux_64]
astropulse_4.35_x86_64-pc-linux-gnu
ap_graphics_4.35_x86_64-pc-linux-gnu

[Common]
ap435.jpg
astropulse_4.35_AUTHORS
astropulse_4.35_COPYING
astropulse_4.35_COPYRIGHT

The [Common] files don't need to be referenced in app_info.xml, but it would be good form to include download links.

The other thing you'll need to post is an accessible manual download location for the files.

Eric says:

http://boinc2.ssl.berkeley.edu/sah/download_fanout/

Excellent - that works, and much faster than the equivalent http://boinc2.ssl.berkeley.edu/beta/download/ (which is stuffed full of AP data files). We can make forum download links for everything necessary.

It's too late (European time) for me to write and test app_info files today, but they'll be ready for lab opening tomorrow.

Thanks for that overview, Richard, that makes building these files easier.

More minimalistic app_info.xml files for running AstroPulse only would contain the following:

[Linux_32]

<app_info>
    <app>
        <name>astropulse</name>
    </app>
    <file_info>
        <name>astropulse_4.35_i686-pc-linux-gnu</name>
        </executable>
    </file_info>
    <file_info>
        <name>ap_graphics_4.35_i686-pc-linux-gnu</name>
        </executable>
    </file_info>
    <app_version>
    <app_name>astropulse</app_name>
    <version_num>435</version_num>
    <file_ref>
        <file_name>astropulse_4.35_i686-pc-linux-gnu</file_name>
        <main_program/>
    </file_ref>
    <file_ref>
        <file_name>ap_graphics_4.35_i686-pc-linux-gnu</file_name>
        <open_name>graphics_app</open_name>
    </app_version>
</app_info>

[Linux_64]

<app_info>
    <app>
        <name>astropulse</name>
    </app>
    <file_info>
        <name>astropulse_4.35_x86_64-pc-linux-gnu</name>
        </executable>
    </file_info>
    <file_info>
        <name>ap_graphics_4.35_x86_64-pc-linux-gnu</name>
        </executable>
    </file_info>
    <app_version>
    <app_name>astropulse</app_name>
    <version_num>435</version_num>
    <file_ref>
        <file_name>astropulse_4.35_x86_64-pc-linux-gnu</file_name>
        <main_program/>
    </file_ref>
    <file_ref>
        <file_name>ap_graphics_4.35_x86_64-pc-linux-gnu</file_name>
        <open_name>graphics_app</open_name>
    </app_version>
</app_info>

I have cut out the common files from my already working app_info.xml. So, at least the [Linux_64] version is tested and works.

Generally i would include a logo file, because a graphical part for the application is available that could show the AstroPulse logo.

---

_\|/_
U r s

TESTING

1) Download links for the files:

[Windows]
astropulse_4.35_windows_intelx86.exe
ap_graphics_4.35_windows_intelx86.exe
libfftw3f-3-1-1a_upx.dll

[Linux_32]
astropulse_4.35_i686-pc-linux-gnu
ap_graphics_4.35_i686-pc-linux-gnu

[Linux_64]
astropulse_4.35_x86_64-pc-linux-gnu
ap_graphics_4.35_x86_64-pc-linux-gnu

[Common - right-click these files and choose 'Save target as...']
ap435.jpg
astropulse_4.35_AUTHORS
astropulse_4.35_COPYING
astropulse_4.35_COPYRIGHT

2) Combination app_info.xml for Windows optimisers - REMOVE [color] TAGS BEFORE USING.

The problem is that optimisers will already have an app_info (RED segment), and they'll all be different. The instructions will have to say "Use a simple text editor like Notepad to add the Astropulse details (BLUE segment) to your existing app_info.xml file, after the opening tag. Remember to do this again every time you make a change to either the SETI or the Astropulse application."

I've loaded this file under BOINC v5.10, and let it communicate with the SETI Main scheduler, both without error messages. Now all we need are some WUs to test it with!

Can anyone say whether we need a <api_version> tag for BOINC v6.2 graphics compatibility, and if so, which version AP uses?

<app_info>
[color=blue]    <app>
        <name>astropulse</name>
    </app>
    <file_info>
        <name>astropulse_4.35_windows_intelx86.exe</name>
        <executable/>
    </file_info>
    <file_info>
        <name>libfftw3f-3-1-1a_upx.dll</name>
        <executable/>
    </file_info>
    <file_info>
        <name>ap_graphics_4.35_windows_intelx86.exe</name>
        <executable/>
    </file_info>
    <app_version>
        <app_name>astropulse</app_name>
        <version_num>435</version_num>
        <file_ref>
            <file_name>astropulse_4.35_windows_intelx86.exe</file_name>
            <main_program/>
        </file_ref>
        <file_ref>
            <file_name>libfftw3f-3-1-1a_upx.dll</file_name>
        </file_ref>
        <file_ref>
            <file_name>ap_graphics_4.35_windows_intelx86.exe</file_name>
            <open_name>graphics_app</open_name>
        </file_ref>
    </app_version>[/color]
[color=red]    <app>
        <name>setiathome_enhanced</name>
    </app>
    <file_info>
        <name>AK_v8_win_SSE2.exe</name>
        <executable/>
    </file_info>
    <app_version>
        <app_name>setiathome_enhanced</app_name>
        <version_num>527</version_num>
        <file_ref>
           <file_name>AK_v8_win_SSE2.exe</file_name>
            <main_program/>
        </file_ref>
    </app_version>
    <app_version>
        <app_name>setiathome_enhanced</app_name>
        <version_num>528</version_num>
        <file_ref>
           <file_name>AK_v8_win_SSE2.exe</file_name>
            <main_program/>
        </file_ref>
    </app_version>[/color]
</app_info>

Arrrrgggghhh - which idiot took indenting out of code display? It used to work.

NB - Yes, it's normal for a SETI app_info to include version info for both 527 and 528 (and often earlier versions as well). It handles the transition from stock (or earlier optimised) apps without trashing work, and is intended to be future-proof for when the variable multiplier becomes mandatory ;-)

Richard, as one who runs optimised apps, I can say that you're doing sterling work here.

Just one minor point: red and green are not the best colours to choose to divide the segments of your app_info.xml files. A significant percentage of the the world's male population will have great difficulty distinguishing between the two. (I'm one of them.)

I'd suggest black and blue, or red and blue, or black and yellow, or some such.

(The impact of your very interesting graph in Message 34300 was probably also lost on a few souls like me.)

---

Point taken.

As to the graphs, I hope you're making the same point to Bill Gates - the colours were the ones automatically assigned by Excel. Microsoft do actually handle accessibility issues reasonably well, and reacted properly when I complained about early versions of Windows Genuine Advantage requiring users to re-type their product key - not easy for a couple of my clients who are totally blind.

As discussed in Astropulse 4.35, I tested this process on my host 28361 running BOINC v6.2.14 as a service under Windows XP SP3.

I downloaded the files using the links I posted a couple of messages ago. Seemed to go OK, and no error messages, but all tasks errored with 'Process creation failed'. It turned out I had only got 120KB of the 452KB main executable file.

Josh, I think we're going to have to be a bit more robust about making the file download idiot-proof (the idiot, in this case, being me).

Could I refer you, as an example, to the Einstein Power User Applications page, maintained by the project developer, Bernd Machenschalk. He links to .zip or .gz archives of the relevent files, and supplies an MD5 hash for the ultra-cautious to compare their download against the published original. Zipping the files would, at the very least, trigger an alert at the unzipping stage if the downloaded file was corrupt or incomplete, instead of not finding out until tasks started to crash (sorry for messing up your success-rate statistics!).

I thought I'd show you the RDCF problem in action on my Plan B machine:


(direct link)

Look at the three AP 4.35 tasks at the bottom. The unstarted ones show a time estimate of 12:37:16, yet the running one has done more than this already, and has still more to go. RDCF at the time this screen-dump was captured was 0.1221, and hasn't fully stabilised yet - compare the 'before and after' times for the MB 6.02 shorties (actually running with AK_V8_SSSE3). This is a Q9300 at stock speed (2.5GHz), with dual-channel 800MHz DDR2 RAM.

If these settings were live on Main, people with 10-day caches and 14-day deadlines would be getting their fingers burnt.

RDCF update.

I let all those VHAR 'shorty' tasks run through, and the RDCF came down to 0.1099. By that stage, BOINC was estimating that it could complete an AP 4.35 task in 11:43:20 - I'm estimating 40:30:00 or thereabouts (reached just over 37% after 15 hours).

I then switched to "Manic Credit Hound Emulation" mode, to see what is about to happen on SETI Main. Reserving one core for my CPDN Beta spinup task, I reckon I've got 3 cores x 14 days x 24 hours, or 1008 hours of crunch time, available within the AP deadline at Main. That would allow me to complete 24 AP tasks at the projected 40.5 hours/task.

So I started bumping the cache. I downloaded my 25th AP task at just 6 additional days (keeping my standard 0.01 day connection interval).

We'll have to see how the scheduler handles the issuing of different types of task, once they've got the final production version sorted out, but a run of VHAR MB, followed by a run of AP, isn't a wildly improbable event.

[Incidentally, I was a bit surprised to get exclusively AP work in this test - I haven't had a single MB task issued by the scheduler since I installed the multi-mode app_info.xml. I'll go over and tell Eric in his scheduler problem thread]

...
[Incidentally, I was a bit surprised to get exclusively AP work in this test - I haven't had a single MB task issued by the scheduler since I installed the multi-mode app_info.xml. I'll go over and tell Eric in his scheduler problem thread]

Possible correlation to the order the apps are listed in app_info.xml? Could you try listing setiathome_enhanced first?

                                                          Joe

Well i decided to do some Astropulse on main,
so i pasted my app_info.xml details for AK_v8_win_SSE41.exe into
Richard's, had a look through it to see if it looked o.k,
but when i restarted it trashed all my Seti MB WU's!!
the result details say 'No main program specified'
put my old app_info.xml back for now, but can't get any more work
as i've got a daily quota of 2 now!!

Claggy

---

@ Joe,

Worth testing, so I tried it on the last available AP-class machine I have accessible for easy testing. Result:

24/07/2008 18:59:54|SETI@home Beta Test|Sending scheduler request: To fetch work
24/07/2008 18:59:54|SETI@home Beta Test|Requesting 12782 seconds of new work
24/07/2008 18:59:59|SETI@home Beta Test|Scheduler RPC succeeded
24/07/2008 18:59:59|SETI@home Beta Test|Message from server: Server error: can't attach shared memory
24/07/2008 18:59:59|SETI@home Beta Test|Deferring communication for 1 hr 0 min 0 sec
24/07/2008 18:59:59|SETI@home Beta Test|Reason: project is down

(and SETI Main isn't much better). Hopefully, they've found the bug and are putting the fix in place! I'll let you know what happens, or you can monitor host 23492.

@ Claggy,

23492 is now the fourth host I've put the combination app_info on: no error messages, 3 are running and one .... waiting. If you'd like to PM me the app_info.xml file you made, and the BOINC messages you got, then I'll have a go at working out what went wrong so we can give guidance to Josh for what instructions should go in the FAQ. (If it can go wrong once, it can go wrong again: and the more errors we can trap/avoid before they happen, the happier everyone will be).

@ Everyone,

In that spirit, please double-check your .exe file downloads from the links I posted: I got the 120KB version (truncated download) again on this box.

The true file sizes are:

astropulse_4.35_windows_intelx86.exe .... 452 KB (462,848 bytes)
ap_graphics_4.35_windows_intelx86.exe ... 288 KB (294,912 bytes)
libfftw3f-3-1-1a_upx.dll ................ 438 KB (448,600 bytes)

- at least, that's what they show as when I've downloaded them using Internet Explorer. Don't accept anything less.

(If it can go wrong once, it can go wrong again: and the more errors we can trap/avoid before they happen, the happier everyone will be).

Wouldn't it be best if instead of giving do-it-yourself instruction pre-made app_infos were made downloadable? Then links to those could be posted to, say, Optimized Apps -thread at Main.

That would leave only two possible errors:
1) Picking app_info for wrong optimized app
2) Forgetting to download AP files

-Juha

...
[Incidentally, I was a bit surprised to get exclusively AP work in this test - I haven't had a single MB task issued by the scheduler since I installed the multi-mode app_info.xml. I'll go over and tell Eric in his scheduler problem thread]

Possible correlation to the order the apps are listed in app_info.xml? Could you try listing setiathome_enhanced first?

                                                          Joe

No, that's not it - host 23492 got issued AP work, even with a 'reversed' app_info (entire setiathome_enhanced block listed before the atropulse block).

Also, the first host I tried, one of my P4 Northwoods, has continued to get MB work at main even using the app_info I posted - doesn't prove much about AP work at Main, of course, just shows that the second application in listing order is capable of being serviced by the anonymous platform mechanism.

(If it can go wrong once, it can go wrong again: and the more errors we can trap/avoid before they happen, the happier everyone will be).

Wouldn't it be best if instead of giving do-it-yourself instruction pre-made app_infos were made downloadable? Then links to those could be posted to, say, Optimized Apps -thread at Main.

That would leave only two possible errors:
1) Picking app_info for wrong optimized app
2) Forgetting to download AP files

-Juha

What would be even more secure would be if the download hosts of the optimised packages could prepare and package a 'combo set' - "SSSE3 optimised MB, plus stock AP, all in one handy little dispenser". They could then be available for alternative download, much as they are already available +/- graphics on some sites. Such pre-packaged bundles would be a useful half-way house before full AP optimisation, which will surely come in due course.

But I don't think I'll suggest it just yet, until we get confirmation that AP 4.35 has indeed tested OK in the field (my first is at 22 hours, 54%+), and that the scheduler problems have been fully resolved.

'combo set'

That would indeed be the next logical step. Even if v8 gets a graphics version the number of different combo packages would stay in reasonable limits.

Of course once we get to the point where there is MB ± graphics & AP ± graphics & maybe different optimizations for AP like there is for MB...

-Juha

Well i decided to do some Astropulse on main,
so i pasted my app_info.xml details for AK_v8_win_SSE41.exe into
Richard's, had a look through it to see if it looked o.k,
but when i restarted it trashed all my Seti MB WU's!!
the result details say 'No main program specified'
put my old app_info.xml back for now, but can't get any more work
as i've got a daily quota of 2 now!!

Claggy

I think we've got a handle on this problem now.

Claggy had an app_info.xml downloaded from Lunatics (I've checked the source), containing lines like

<executable />
<main_program />

(with spaces)


I've always written those tags without spaces, and I've reproduced Claggy's problem on a machine here by adding the spaces. Further clarification in due course, no doubt, but for the time being - check for spaces in those tags, and delete if present.

grrrrrr............found a typo in my linux app_info's that deactivated the graphics part.

Corrected more minimalistic app_info.xml files for running AstroPulse only would contain the following:

[Linux_32]

<app_info>
<app>
<name>astropulse</name>
</app>
<file_info>
<name>astropulse_4.35_i686-pc-linux-gnu</name>
<executable/>
</file_info>
<file_info>
<name>ap_graphics_4.35_i686-pc-linux-gnu</name>
<executable/>
</file_info>
<app_version>
<app_name>astropulse</app_name>
<version_num>435</version_num>
<file_ref>
<file_name>astropulse_4.35_i686-pc-linux-gnu</file_name>
<main_program/>
</file_ref>
<file_ref>
<file_name>ap_graphics_4.35_i686-pc-linux-gnu</file_name>
<open_name>graphics_app</open_name>
</file_ref>
</app_version>
</app_info>

[Linux_64]

<app_info>
<app>
<name>astropulse</name>
</app>
<file_info>
<name>astropulse_4.35_x86_64-pc-linux-gnu</name>
<executable/>
</file_info>
<file_info>
<name>ap_graphics_4.35_x86_64-pc-linux-gnu</name>
<executable/>
</file_info>
<app_version>
<app_name>astropulse</app_name>
<version_num>435</version_num>
<file_ref>
<file_name>astropulse_4.35_x86_64-pc-linux-gnu</file_name>
<main_program/>
</file_ref>
<file_ref>
<file_name>ap_graphics_4.35_x86_64-pc-linux-gnu</file_name>
<open_name>graphics_app</open_name>
</file_ref>
</app_version>
</app_info>

Sorry for that typo.

---

_\|/_
U r s

...it trashed all my Seti MB WU's!!
...
Claggy

I think we've got a handle on this problem now.

Claggy had an app_info.xml downloaded from Lunatics (I've checked the source), containing lines like

<executable />
<main_program />

(with spaces)


I've always written those tags without spaces, and I've reproduced Claggy's problem on a machine here by adding the spaces. Further clarification in due course, no doubt, but for the time being - check for spaces in those tags, and delete if present.

Well spotted, thanks!

                                                               Joe

I see from the seti@home apps page that AP4.35 is available,

Question?

Will both AP4.35s apps (seti main and beta) run on the same host together without interaction, just curious?

Michael

F-Ambrose ...

I'm not fully familiar with this, but it's my opinion that they will work OK under a common system. The WU is controlled by either SETI Main or SETI Beta, so that's where the system will look for the applicable software. Granted, there might be duplicate (mostly) software under more than one location, but it'll run from the 'callpoint' .....

---

If I've lived this long, I've gotta be that old