The function of this SetiBeta/Astropulse site is to test the applications before release into the wild on the main Seti site.

Therefore, it should only be of interest to you if you fulfil most of the following statements;
1. You can visit these pages regularly, preferable more than once per day.
2. You are not worried about credits.
3. You don’t mind having to abort work and empty your work cache.
4. You are prepared for long processing times, especially in the initial stages of application testing.
5. You don’t mind units crashing and reporting said crashes.
6. You do not expect to run optimised applications.
a. Optimised in meaning faster.
b. Applications compiled to run on different platforms, or to fix specific problems are acceptable. (i.e. Joe’s Win9x Enhanced app)
c. Running your own, controlled, optimised application, after you have tested it off-line. Is probably acceptable if it passes verification, and when it is spotted, and it will be, you ignore all requests for it to given out to strangers.

Visiting

When running test application things can change rapidly, and yet they stay static, with no news for weeks sometimes.Therefore you need to visit regularly so that time is not wasted processing with:
1. Faulty application
2. Faulty data.
3. Be prepared to help other volunteers, especially if you have the resources, when they see problems that haven’t affected your hosts.
a. For example I have oldish AMD and Dual P3 that normally don’t crunch for BOINC Projects. But I will fire them up, using Win 9x, 2000 Pro, 2000 Server or 2003 server as required. If they are not busy, testing electronic devices, their main function.

Credits
Credits at test sites are given at the developer’s discretion. They are not automatic. If granted they are quite often awarded manually or via a script, when the developer has a few quiet moments.
This can be for various reasons.
Nearly all the units produced errors.
Different results were obtained on different platforms.
Units ran for ‘long’ time before it was found application was buggy.

Work Cache
If it is found the new app or the data is faulty, it is not unknown for either of the following actions;
a. Suspend project, to see if there is a remedy,
b. Abort all units, and wait for new app or units, as applicable.
Therefore it not wise to have long ‘connect to network’ setting. As not visiting site, can result in many hours crunching for absolutely no gain to you or the project. And manually having to abort 100’s of units is a pain in the a**e.

Processing Times
At the start of testing a new application the processing times will probably not be known. Therefore you have to expect long crunching times.
The first priority for the developer is to check the science is correct. Only then, if it found the processing times are longer than expected will they look at speeding things up. Sometimes this is done by volunteers. (see, enhanced or Einstein before S5R2, [Akosf]).

Crashes
When testing units will crash, we are here to report those crashes, and assist the developers in removing the bugs prior to release on the main site. Buggy applications on a projects main site tend to produce a lot of negative posts, see Einstein S5R2 or Pedictor, there the active hosts are down from over 17,000 to under 3,000, although there are other reasons we will not go into here.

Optimisation.
The Seti Enhanced application in its initial Beta stages took 10’s of hours to process a unit. By the time it was released, on to the main site, the generic application was 5 or 6 times quicker. Some of this was speed up was enabled by volunteer optimisers who gave their work to Eric.
Hopefully we can expect to see similar reductions for AP.

Seti applications are open source, and can therefore be worked on by the volunteers. This enables the volunteers to either produce applications for other platforms or to shorten the processing time.
Since then the optimisers have halved that, and a VLAR unit can be done in under 15 minutes on new computers. This is done by using different compilers, unavailable (unaffordable) at Berkeley and using CPU specific features, MMX, SSEn etc, which Berkeley cannot do due to a lack of resources (funds and man hours).

This is a fantastic piece!

@moderators. Could someone peuölease make this sticky:-)

Thanks!
Carl

That write-down is a very good piece of work, Andy, that summarizes nearly all the facts and necessities for a project state like Astropulse/Seti@home beta is in now.
Thank you very much.

---

_\|/_
U r s

Carl and Urs,
Thanks, also thanks to moderator for making Sticky.

Andy

A few things I would like to add to this.

The function of this SetiBeta/Astropulse site is to test the applications before release into the wild on the main Seti site.

Therefore, it should only be of interest to you if you fulfil most of the following statements;
1. You can visit these pages regularly, preferable more than once per day.
2. You are not worried about credits.
3. You don’t mind having to abort work and empty your work cache.
4. You are prepared for long processing times, especially in the initial stages of application testing.
5. You don’t mind units crashing and reporting said crashes.
6. You do not expect to run optimised applications.
a. Optimised in meaning faster.
b. Applications compiled to run on different platforms, or to fix specific problems are acceptable. (i.e. Joe’s Win9x Enhanced app)
c. Running your own, controlled, optimised application, after you have tested it off-line. Is probably acceptable if it passes verification, and when it is spotted, and it will be, you ignore all requests for it to given out to strangers.

Visiting

When running test application things can change rapidly, and yet they stay static, with no news for weeks sometimes.Therefore you need to visit regularly so that time is not wasted processing with:
1. Faulty application
2. Faulty data.
3. Be prepared to help other volunteers, especially if you have the resources, when they see problems that haven’t affected your hosts.
a. For example I have oldish AMD and Dual P3 that normally don’t crunch for BOINC Projects. But I will fire them up, using Win 9x, 2000 Pro, 2000 Server or 2003 server as required. If they are not busy, testing electronic devices, their main function.

Credits
Credits at test sites are given at the developer’s discretion. They are not automatic. If granted they are quite often awarded manually or via a script, when the developer has a few quiet moments.
This can be for various reasons.
Nearly all the units produced errors.
Different results were obtained on different platforms.
Units ran for ‘long’ time before it was found application was buggy.

Work Cache
If it is found the new app or the data is faulty, it is not unknown for either of the following actions;
a. Suspend project, to see if there is a remedy,
b. Abort all units, and wait for new app or units, as applicable.
Therefore it not wise to have long ‘connect to network’ setting. As not visiting site, can result in many hours crunching for absolutely no gain to you or the project. And manually having to abort 100’s of units is a pain in the a**e.

Processing Times
At the start of testing a new application the processing times will probably not be known. Therefore you have to expect long crunching times.
The first priority for the developer is to check the science is correct. Only then, if it found the processing times are longer than expected will they look at speeding things up. Sometimes this is done by volunteers. (see, enhanced or Einstein before S5R2, [Akosf]).

Crashes
When testing units will crash, we are here to report those crashes, and assist the developers in removing the bugs prior to release on the main site. Buggy applications on a projects main site tend to produce a lot of negative posts, see Einstein S5R2 or Pedictor, there the active hosts are down from over 17,000 to under 3,000, although there are other reasons we will not go into here.

Optimisation.
The Seti Enhanced application in its initial Beta stages took 10’s of hours to process a unit. By the time it was released, on to the main site, the generic application was 5 or 6 times quicker. Some of this was speed up was enabled by volunteer optimisers who gave their work to Eric.
Hopefully we can expect to see similar reductions for AP.

Seti applications are open source, and can therefore be worked on by the volunteers. This enables the volunteers to either produce applications for other platforms or to shorten the processing time.
Since then the optimisers have halved that, and a VLAR unit can be done in under 15 minutes on new computers. This is done by using different compilers, unavailable (unaffordable) at Berkeley and using CPU specific features, MMX, SSEn etc, which Berkeley cannot do due to a lack of resources (funds and man hours).

1. Casual Beta Crunchers (AKA Seti Refugee's)
As it stands it would probably put off the casual Beta crunchers. I guess these are mainly normal Seti people who try to keep their cpu's warm when the main site is having problems.

All I ask fro these refugees is, please complete the units.
We have far too many "too many total results" which the validation sequence usually identifies a bad data, when it is actually bad users, who either abort or do not return them. Example

2. Result Duration Correction Factor (RDCF or DCF)
Due to initial unknown crunch times for new applications, AP in this case, your hosts RDCF for Beta, will probably go through the roof. Mine went from under 0.5, when we were crunching enhanced only, to over 5.0 when the first AP unit was returned, even though they Crashed early due to finding 30 pulses.

This means that after you have done an AP unit, and when you ask for more work and find the server has only Enhanced units. You will probably only download one or two where before you down loaded five or six.
At this stage do not increase your 'connect to network setting'. As the enhanced units will start decreasing the RDCF and when AP units are available again it is likely that you will download more that one/cpu. Which will probably mean more time and effort wasted.

Andy

Josh posted information about what is happening within Astropulse...

Astropulse Algorithms and Science

For Standalone Testing he added information about two switches for "piping" more information to the stderr.txt file

When you start the ap_client.exe you can start it with:

ap_client -debug_msg
ap_client -debug_loop_msg
ap_client -debug_msg -debug_loop_msg

You are welcome to add more information about your experiences... Specific testing information should be in the Forum Thread about the specific Version being tested.

Thank You Josh

---

Thanks to Paul and Friends
Please consider a Donation to the Seti Project