It looks like Astropulse will be released to the general public very soon. The fraction of erroring Astropulse results has dropped almost to the same level as for seti@home. The main task that remains for us is to ensure that Astropulse is only sent to fast computers, so that people aren't crunching the same workunit for 3-4 weeks. We will also allow users to choose to run only seti@home or only astropulse, although this may not be an option initially.

Astropulse beta will stay around, of course, as a testing ground for all new features and fixes that we add to Astropulse. There may well be problems after the release that will make further beta testing very important. Thanks for all your help that has made this possible, and I hope you continue with the beta project.

Applause!

It looks like Astropulse will be released to the general public very soon. The fraction of erroring Astropulse results has dropped almost to the same level as for seti@home. The main task that remains for us is to ensure that Astropulse is only sent to fast computers, so that people aren't crunching the same workunit for 3-4 weeks. We will also allow users to choose to run only seti@home or only astropulse, although this may not be an option initially.

Astropulse beta will stay around, of course, as a testing ground for all new features and fixes that we add to Astropulse. There may well be problems after the release that will make further beta testing very important. Thanks for all your help that has made this possible, and I hope you continue with the beta project.

---

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

Fast computers = Min specs? dual core or higher?

---

What I was told as far as Seti Main, they are looking for a set of machines that can complete the "Result" in roughly 4 days (96 hours or 345600 seconds)

Fast computers = Min specs? dual core or higher?

From the same conversation it was mentioned that an opt-in or opt-out "preferences set" was being considered.

---

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

What I was told as far as Seti Main, they are looking for a set of machines that can complete the "Result" in roughly 4 days (96 hours or 345600 seconds)

Fast computers = Min specs? dual core or higher?

From the same conversation it was mentioned that an opt-in or opt-out "preferences set" was being considered.

Thinking about it that statement does not compute.

A 4 day deadline would limit the hosts capable to most modern desktop computers that are on 24/7 with resource share greater than 50%. 99% of laptops will not meet that spec.

Or the equivalent of 96hrs processing on a computer that is ON and BOINC/Seti is running 25% of the time, (42hrs/week). That I assume would equate to a four week deadline, assuming the computer is used for other tasks.

Is the opt in/out preference to be at default 'in' or 'out'. If 'in' then unless a lot of computer usage stats are considered I think a lot of units are not going to be returned on time. If 'out' then a lot of computers (read majority) are never going to do AP.

Andy, I think you're being slightly pessimistic here.

Looking for a target 'class' of computer with a final CPU time of 345600 seconds or less, does not of itself make any statement about deadlines. I think we've already won the battle about deadlines (the latest batch seem to be set at 30 days, which is tight, but plausible, for that class of machine). And I can't see Eric setting an AP deadline which is shorter than the shortest shorty at SETI (7 days).

I'd be interested to hear a definition of "soon" for the release. Matt has stated in public that "we're hoping to release Astropulse before the end of the week." (reference). That seems awfully close, if things like this are only being "considered".

There are other things to consider, too. A lot of AP-class machines at SETI are going to be running optimised applications (I remember we had quite a lot of difficulty finding un-optimised fast hosts, when doing the data capture to validate Joe's revised deadline curve for MB). So they will be excluded from AP work, without manual intervention.

Which at least excuses us from thinking about RDCF and optimised SETI apps. The current AP tasks still seem to be targetting an RDCF of 0.4, while MB 6.02 seems to be nearer an RDCF of 0.2 on AP-class machines. That 2:1 discrepancy in estimates becomes 4:1 when running an AK_V8 optimised app at roughly double the speed. And that brings us back to deadlines again: a 10-day cache (why people run them, I'll never know, but they do) calculated on an AK_V8 RDCF, will turn into 40 days of AP crunching, and blow the 30-day (hypothetical) deadline.

Incidentally, why are we deliberately supplying false estimates? Surely the target RDCF should be 1.000000, for both AP and MB? I can see an argument for something slightly lower (initial work fetch for new hosts won't be over-optimistic), but anything below say 0.8 shouldn't be a target, it's just a historical aretfact introduced because the SETI estimates have been allowed to get out of line when optimisations have been retro-fitted into the stock applications.

More work needs to be done on this.

I loved Pappa's post at Orbit about the need for administrators to post about the concerns and problems expressed by testers. We need some of that spirit here.

Me Pessimistic, never, just acting as devil's advocate again (BOINC ID 666).
I hate sound bites and incomplete explanations.

Computers capable of processing a unit in 96 hours means absolutely sh1t if that computer is only on 1 hour per day, when a lower class computer that is on 24/7 can complete unit within half the deadline, and do another project as well.

The RDCF cannot be set to 1.0 because that was the aim for the original Seti app on BOINC. Since then there has been a lot of optimisation and cpu improvements, that have lowered the RDCF. And if 0.4 is the target now then we are still in trouble as in the last few days with lots of VHAR units on the main site one of my computers actually went below 0.1, using opt app, the first time I have seen that.

Richard, Andy et al

Over time I have worked to get information and point to issues. Sometimes that is information that I get from phone calls to Eric. To that extent what I thought I heard was not necessarily what Eric meant... Thus I become cautious (sanitized). Thankfully, things happen which corrects the problems or you get questions and/or other answers. Some of that gets into BOINC Alpha to fix other things.

The Important Part is that things You and Everyone put in here sometimes gets acted on immediately and some things take a bit of time. Overall, counting on delay You the Volunteer Testers have provided so much that has made many things "easy" for the Users in Seti Main. I have to Add that Many of You Here are involved in many aspects of BOINC, Seti and Other Projects. I like to think that some of what you learned here has made that easier. Congrats!

Josh has noted that when you do not get direct questions or answers that You as a group have provided complete and important feedback. Without putting him in the spotlight he has at points in time asked me for what you are looking for. He is sensitive to what you say, so without being the person that interepts. He sees what is happening and we all wish he would say more... Yes I do know that things are very complex right now. "WE" have an Apple that we are trying to match to an Orange. Neither of which are perfect... Not to mention Seti Server issues.

What you know will be very Important in Seti Main.

Yes, I do keep asking for information to be posted. That not quite being what we hoped for, I do answer from what I know.

Thank You All, Keep Working. I Will.

In the morning, I will call Eric

Al

---

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

Me Pessimistic, never, just acting as devil's advocate again (BOINC ID 666).
I hate sound bites and incomplete explanations.

Computers capable of processing a unit in 96 hours means absolutely sh1t if that computer is only on 1 hour per day, when a lower class computer that is on 24/7 can complete unit within half the deadline, and do another project as well.

The RDCF cannot be set to 1.0 because that was the aim for the original Seti app on BOINC. Since then there has been a lot of optimisation and cpu improvements, that have lowered the RDCF. And if 0.4 is the target now then we are still in trouble as in the last few days with lots of VHAR units on the main site one of my computers actually went below 0.1, using opt app, the first time I have seen that.

Agree with you. Did post a similar comment over on main. It's not what you run it on but how you run it. I think it will have to be run as a dedicated project rather then a credit hungry one.

But over on main it looks like an early retirement for my laptop 1.7GHz 1% an hour on a good day just outside the 96 hours.

Michael

Me Pessimistic, never, just acting as devil's advocate again (BOINC ID 666).
I hate sound bites and incomplete explanations.

Computers capable of processing a unit in 96 hours means absolutely sh1t if that computer is only on 1 hour per day, when a lower class computer that is on 24/7 can complete unit within half the deadline, and do another project as well.

The RDCF cannot be set to 1.0 because that was the aim for the original Seti app on BOINC. Since then there has been a lot of optimisation and cpu improvements, that have lowered the RDCF. And if 0.4 is the target now then we are still in trouble as in the last few days with lots of VHAR units on the main site one of my computers actually went below 0.1, using opt app, the first time I have seen that.

Agree with you. Did post a similar comment over on main. It's not what you run it on but how you run it. I think it will have to be run as a dedicated project rather then a credit hungry one.

But over on main it looks like an early retirement for my laptop 1.7GHz 1% an hour on a good day just outside the 96 hours.

Michael

As I am at home today, I did some looking around and it would appear that the average Seti host does about 120cr/day.
That would be less than 2.5 average units per day.
Most hosts are P4 @ 3GHz, and although info is sketchy they (P4's) could represent about 50% of population.
Your AP results so far indicate about 42 cr/hr, that would be about 40% higher than stock app for multibeam, thats from my Q6600 and E6600 computers.
My RDCF for Seti Beta, after latest run of MB units and before AP units have completed is 0.32 on duo and 0.28 on quad. So looks like aim for 0.4, on Intel core2 cpu's is an interesting concept.

Michael's Laptop is a T2080 cpu, a computer that should not be on the list of computers barred from doing AP. But my PentM 1.86GHz, only 3 years old, probably is, as I it took ~600k secs (167hrs) to complete an AP unit. Note the PentM is two years younger, and faster overall, than our P4 HT 3GHz retired computer.

The 4 day idea is apparently intended mainly so that users don't get bored and drift away. It also allows a host to participate in many projects without AP work having to be done at high priority, and it will tend to minimize the server-side load due to average turnaround time. All in all, I think it's reasonable for starting AP on main. Certainly there are many cases where user preferences will conflict to some extent, but overall it should not cause much grief.

If the same data is split by an mb_splitter and an ap_splitter, there's about 40.4 MB WUs for each AP WU (based on overlap giving 85 second WU start intervals for mb and no overlap giving 13.42 for ap). I think even the fast hosts will get quite a few MB WUs.

When the preferences are updated to allow user choice, I hope that even those with systems marginal for doing AP work will be allowed to enable it. Ideally, the default settings for each host should be based on speed so adding the preference doesn't change what the host is doing. Then the user could change the setting as desired but those who are running on autopilot won't be inconvenienced.

                                                                  Joe

Even if the preference is for speed there has to be either, a check that the host is on Seti enough hours to complete unit, preferably without going to high priority, or a longer deadline.

If it is the longer deadline then slower machines that are devoted 24/7 to Seti can also do the work.

The check to see if host is on sufficient hours etc would only increase server load, not a good thing. Because the only way I can see if enough time is devoted to Seti, or any other project is actually calculate the time taken for the results returned in the last x days, or do a guestimate from the RAC, assuming you have checked which app they are running.

The other thing that springs to mind is download limit. I personally would not want to see one unit downloaded for each cpu, putting a tight deadline in that situation would cause all projects to fight for priority mode on the computer. And we will go into the the panic, rest, panic cycle.

Sorry, but I do not see any of the present idea's working, once it goes to the main site.


It has been bad enough here, with statements saying we are releasing new app, could you info any prob's etc. Only to find there were only a thousand units produced and they have all gone and you did not get one on any of your computers, Then when you do get them they are resends because the server issued too many to some hosts and they have either aborted them or failed to meet deadline, and of course by then we have gone through two revisions of the application. Or we have to wait days because there is a large amount of the other project to clear first.

Sorry if I am ranting on a bit but unless I am mistaken I doi not think this has been thought out very well. I hope I am wrong but I am not holding my breath.

We also need the AP FAQ completed before release, so that the rabble can have some idea what they have been waiting for. And also know why they have AP on some computers and not on others.

I take it these enhanced WU's will be an initial of two and not as they are at present three. At the moment there seems to be as many cancelled by server as completed or at times it appears that way.

Michael

Even if the preference is for speed there has to be either, a check that the host is on Seti enough hours to complete unit, preferably without going to high priority, or a longer deadline.

If it is the longer deadline then slower machines that are devoted 24/7 to Seti can also do the work.

The check to see if host is on sufficient hours etc would only increase server load, not a good thing. Because the only way I can see if enough time is devoted to Seti, or any other project is actually calculate the time taken for the results returned in the last x days, or do a guestimate from the RAC, assuming you have checked which app they are running.

The Scheduling-server already calculates expected Run-time based on wu's fpops_est and delay_bound (deadline), and clients on_frac, active_frac, resource_share and so on, so this won't give any extra load at all.

There's been two Astropulse-specific changes done to Scheduling-server earlier this week, but usable by all projects. If application is "hard_app", the estimated run-time is increased by 30%. Also, for "hard_app", the checks for estimated run-time is not by-passed, even if client is out of work.

No idea if the "4 days" that has been mentioned is cpu-time or run-time...

Sirius B:

Fast computers = Min specs? dual core or higher?

The algorithm will take the computer's FLOPS, and multiply by the fraction of the day that the computer is running. (Or, rather, has been running historically.) Then it multiplies by the number of seconds of cpu time required to process the workunit. Then it adds 30%. If that amount is greater than the deadline (which is currently 30 days, but could be shortened after this change), then the workunit can be sent to that host.
If you want to calculate min specs, use the fact that an astropulse workunit takes about 4e14 floating point operations. If the deadline is 2 weeks and you are processing 100% of the time, then you need 430 MFLOPS. If 25% of the time, then you need 1.7 GFLOPS.

Richard:

I'd be interested to hear a definition of "soon" for the release. Matt has stated in public that "we're hoping to release Astropulse before the end of the week." (reference). That seems awfully close, if things like this are only being "considered".

How about soon = Monday? No guarantees though.

Winterknight:

We also need the AP FAQ completed before release, so that the rabble can have some idea what they have been waiting for. And also know why they have AP on some computers and not on others.

If people could compose and post some potential FAQs to the forum (you write the questions, I'll write the answers), that would be helpful for me. I don't promise to answer them all, but it will give me a sense of what people are wondering about. Of course, the average volunteer probably has more basic questions than the average beta tester ...

Sirius B:

Fast computers = Min specs? dual core or higher?

The algorithm will take the computer's FLOPS, and multiply by the fraction of the day that the computer is running. (Or, rather, has been running historically.) Then it multiplies by the number of seconds of cpu time required to process the workunit. Then it adds 30%. If that amount is greater than the deadline (which is currently 30 days, but could be shortened after this change), then the workunit can be sent to that host.
If you want to calculate min specs, use the fact that an astropulse workunit takes about 4e14 floating point operations. If the deadline is 2 weeks and you are processing 100% of the time, then you need 430 MFLOPS. If 25% of the time, then you need 1.7 GFLOPS.

Richard:

I'd be interested to hear a definition of "soon" for the release. Matt has stated in public that "we're hoping to release Astropulse before the end of the week." (reference). That seems awfully close, if things like this are only being "considered".

How about soon = Monday? No guarantees though.

Winterknight:

We also need the AP FAQ completed before release, so that the rabble can have some idea what they have been waiting for. And also know why they have AP on some computers and not on others.

If people could compose and post some potential FAQs to the forum (you write the questions, I'll write the answers), that would be helpful for me. I don't promise to answer them all, but it will give me a sense of what people are wondering about. Of course, the average volunteer probably has more basic questions than the average beta tester ...

First draft was written some time ago.

Even if the preference is for speed there has to be either, a check that the host is on Seti enough hours to complete unit, preferably without going to high priority, or a longer deadline.

If it is the longer deadline then slower machines that are devoted 24/7 to Seti can also do the work.

The check to see if host is on sufficient hours etc would only increase server load, not a good thing. Because the only way I can see if enough time is devoted to Seti, or any other project is actually calculate the time taken for the results returned in the last x days, or do a guestimate from the RAC, assuming you have checked which app they are running.

The Scheduling-server already calculates expected Run-time based on wu's fpops_est and delay_bound (deadline), and clients on_frac, active_frac, resource_share and so on, so this won't give any extra load at all.

There's been two Astropulse-specific changes done to Scheduling-server earlier this week, but usable by all projects. If application is "hard_app", the estimated run-time is increased by 30%. Also, for "hard_app", the checks for estimated run-time is not by-passed, even if client is out of work.

No idea if the "4 days" that has been mentioned is cpu-time or run-time...

JM7 not that long ago stated that resource share is NOT included in the calculation, and also that each project does not know resource share figures for other projects that host is connected to. The figures you mention are BOINC figures not specific Project figures, so even if these are used it could still give the host too much work.
If you set up a new host with x day cache BOINC will try to get x days cache from each project NOT x days cache total, until the LTD's are sorted.
e.g. if you look at host 351 with a SetiBeta resource share of 12.5%, (50% of one cpu on quad) with 2 day cache, you will see it downloaded two AP units when Seti main was off-line on the 15th. Not a problem here because of deadline, but the first has just completed (17th), 66 hours after it was issued, and the second has only done ~2 hrs (5.04%).

Also if RDCF is based on MB work and you use an optimised app the RDCF will be very low, mine hovers between 0.1 and 0.125 on Seti, then if a host is connected to Seti and A.N.Other project and the A.N.Other project is off-line or out of work the the scheduler will pick up extra work from Seti. If this extra work is now AP units then 3 or 4 times too much will be downloaded.

vonkorff:

...
If you want to calculate min specs, use the fact that an astropulse workunit takes about 4e14 floating point operations. If the deadline is 2 weeks and you are processing 100% of the time, then you need 430 MFLOPS. If 25% of the time, then you need 1.7 GFLOPS.
...

My Willamette P4 system has a BOINC WMIPS of 809.92 and takes 14.3 days at near 100% to do an AP WU. My Pentium-M has a WMIPS of 1235.8 and takes just over 5 days on AP work, again at near 100%. I assume by "MFLOPS" you mean that BOINC benchmark. I suspect the rough correlation between the benchmarks and real work has an offset such that using overall averages leaves the "min specs" criterion significantly different than you intend.

                                                                Joe

Calculation of run time from BOINC benchmarks is flawed.

Mine CPU type GenuineIntel
Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz [x86 Family 6 Model 15 Stepping 11]
Number of CPUs 4
Operating System Microsoft Windows XP
Professional Edition, Service Pack 2, (05.01.2600.00)
Memory 2046.42 MB
Cache 244.14 KB
Swap space 3416.73 MB
Total disk space 152.66 GB
Free Disk Space 119.74 GB
Measured floating point speed 2938.85 million ops/sec
Measured integer speed 6665.28 million ops/sec

Time for AP unit less than 40 hours

Pappa'sCPU type AuthenticAMD
AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ [x86 Family 15 Model 67 Stepping 3]
Number of CPUs 2
Operating System Microsoft Windows XP
Professional Edition, Service Pack 3, (05.01.2600.00)
Memory 2047.48 MB
Cache 488.28 KB
Measured floating point speed 2988.36 million ops/sec
Measured integer speed 5424 million ops/sec

Time for AP unit more than 80 hours.

Resource share for project is a number. Projects have no indication of resource share of any other projects host is attached to.

These figures are BOINC figures and are the same for that host on all projects +/- iota.

On same host					SetiBeta		Seti		Einstein
% of time BOINC client is running		99.8285%		99.8305%	99.8296%
While BOINC running, % of time work is allowed	99.9374%		99.9381%	99.9377%
Average CPU efficiency				0.988077		0.987559	0.987517