Please Read Before Posting

Message boards : AstroPulse : Please Read Before Posting
Message board moderation

To post messages, you must log in.

AuthorMessage
Winterknight
Volunteer tester

Send message
Joined: 15 Jun 05
Posts: 707
Credit: 5,565,069
RAC: 1,760
United Kingdom
Message 22983 - Posted: 18 May 2007, 7:08:27 UTC
Last modified: 18 May 2007, 7:11:19 UTC

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).
ID: 22983 · Report as offensive     Reply Quote
Profile Demiurg
Volunteer tester
Avatar

Send message
Joined: 14 Apr 07
Posts: 506
Credit: 15,684
RAC: 0
Sweden
Message 22986 - Posted: 18 May 2007, 10:13:57 UTC

This is a fantastic piece!

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

Thanks!
Carl
ID: 22986 · Report as offensive     Reply Quote
Urs Echternacht
Volunteer tester
Avatar

Send message
Joined: 18 Jan 06
Posts: 1038
Credit: 18,734,730
RAC: 0
Germany
Message 22993 - Posted: 18 May 2007, 13:35:32 UTC
Last modified: 18 May 2007, 13:35:45 UTC

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
ID: 22993 · Report as offensive     Reply Quote
Winterknight
Volunteer tester

Send message
Joined: 15 Jun 05
Posts: 707
Credit: 5,565,069
RAC: 1,760
United Kingdom
Message 22997 - Posted: 18 May 2007, 14:13:59 UTC

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

Andy
ID: 22997 · Report as offensive     Reply Quote
Winterknight
Volunteer tester

Send message
Joined: 15 Jun 05
Posts: 707
Credit: 5,565,069
RAC: 1,760
United Kingdom
Message 23162 - Posted: 20 May 2007, 6:36:49 UTC - in response to Message 22983.  
Last modified: 20 May 2007, 6:41:27 UTC

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
ID: 23162 · Report as offensive     Reply Quote
Profile Pappa
Volunteer tester
Avatar

Send message
Joined: 13 Nov 05
Posts: 1724
Credit: 3,121,901
RAC: 0
United States
Message 30543 - Posted: 29 Oct 2007, 23:21:21 UTC

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
ID: 30543 · Report as offensive     Reply Quote

Message boards : AstroPulse : Please Read Before Posting


 
©2019 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.