Thanks for all the helpful messages! You’re right; only 9.09% of my CPU time is dedicated to this project. Interestingly, that doesn't seem to have the same effect on all the other projects I crunch for. Presumably this one has some very dedicated hosts which gobble up workunits as fast as they come out! Perhaps I should consider either increasing the allocation of time to this project or just concentrating on other projects. I shall ponder...

Thanks again.

From results on my hosts, I think a host with a S@H RAC of about 100 will be able to do AP work though it may require running the work in high priority. The BOINCSTATS breakdown of S@H hosts indicates there are 1977537 total, 353386 active, and 128478 with RAC of 100 or more. It looks like many active hosts may be forced out of their normal pattern by AP work, and perhaps quite a few won't be able to complete AP work within 30 days. Many of the hosts with RAC around 100 are dual or quad CPU systems, the low RAC must be because they only do S@H work part time (sharing with other projects, only powered up a few hours a day, or using preferences to limit CPU usage).

BOINCSTATS lists 4012 CPU types for S@H, of which 2263 have 0.00116 credits per CPU second or higher. That's the credit/time rate corresponding to 100 RAC per CPU when crunching 24/7. The 1749 types with lower credit/time rate probably represent only a small fraction of active hosts, but it still suggests that there will be many hosts which simply cannot do AP work within deadline.

Earlier today I was looking at the BOINC Application filtering mechanism which provides a project preference setting to opt out of getting work for specific applications. The Scheduler code which makes use of that option doesn't seem too intensive, and AP work should reduce the number of requests to the Scheduler anyhow. I hope the project will enable it, that is far simpler than forcing users to use app_info.xml files to control what they get.

Joe

http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=1146437
http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=3927896

Currently suspended for a few hours to let other projects do some work.

50.000% 155:00:15 hours
75.000% 231:32 hours
80.000% 246:37:20 hours
82.002% 252:30 hours

BOINC estimated time to complete is 55:49:55 hrs, which macthes my hand calculated estimate fairly well.

Both wingman "Anonymous" and my host went past deadline on 30th May, both replacment tasks are currently unsent.

With luck I should complete this in the next 3 - 4 days. AMD Athlon 2200+, Win XP.

One problem that I noticed is that BOINC wanted to keep this task running even though another (RALPH@home) task was < 2 hours from deadline with > 2 hours work left.

I suspended the AP task to let RALPH finish and it completed OK, but BOINC 5.10.45 may have let the other task go over deadline if I had not intervened.

...
Can't delete previous state file; Access is denied. (0x5)
Can't rename current state file to previous state file; Cannot create a file when that file already exists. (0xb7)

Could these be related and caused by running BOINC on a drive other than C? I am currently running Boinc as a service with the program and data on drive E

Pappa -

I'd love to run some AP units, but due to the lengthy prior versions, I'm in a debt situation to other projects. Hope to be back soon.

Sorry, I cannot agree that 4.31 is faster than 4.30 - it is three times SLOWER!

On my 1.6 GHz-Pentium4, I cancelled the last 4.30-unit on the deadline-day after 200 hours of computation - there were still more than 300 hours left. I downloaded one 4.31 Astropulse-WU, and: surprise, surprise: it will take 1400 HOURS instead of 500 now!

How will it be finished until 6th of June? Again, deadlines are VERY short!!!

But, by the way, like always before, the columns "processor time" (now: 17hours), "Percentage" (now 10%) and "Deadline" (another 1135 hours) do not corrsepond at all!

Yours, Gero

Gero,

I don't know how closely you've been following the conversation so far, but please be aware that the figure of 1,400 hours - which I assume you are reading from the 'to completion' column in BOINC Manager, is very much an ESTIMATE, and at this stage in the testing of a new program, likely to be a very inaccurate estimate.

Have a look at the results for my host 23492. 365 Ksecs has come down to 152 Ksecs: that's the speedup from 4.30 to 4.31

The general experience with Astropulse is that it proceeds very steadily from beginning to end. That machine of mine used to be 1% in 1 hour, 10% in 10 hours, 100% in 100 hours. Since your machine has done 10% in 17 hours, you can have a strong expectation that the final run time will be 170 hours, or just a faction over a week.

Let us know how you get on.

Keith et al

At this point the purpose of 4.30 is complete. We are working to get the 4.31 tested. I know that you have quite a few hours into it but a Seti Beta project "Reset" should return the same WU's with 4.31 (that also needs to be tested, but would "normally" only recommend it "Very early into the WU").

I reset one with less than 30 hours to complete and one that was 50% done...

Note: after the project Reset, remember to restart BOINC.

Regards

Al

So, what are the current deadlines (with AP 4.31)? If they are still 14 days, I am not brave enough to allow new workunits...

My Athlon XP 2200+ is currently just over 50 hours into a 4.30 WU. It was doing a 4.29, but that crashed last week. 4.30 suspends/resumes OK.

7.797% 24 hrs 307.811
10.000% 30.5 hrs 305.0
15.612% 48 hrs 307.456
16.330% 50 hrs 306.185
16.760% 51.5 hrs 307.279

Those compare to a BOINC Manager estimated time at completion of 316 hours, so progress seems to be fairly linear so far.

Keith.

Update on this WU, now just past 25%.

19.515% 60:00 hrs
307.456 estimated at completion

20.000% 61:30 hrs
307.5 estimated at completion

25.002% 77:12 hrs
308.775 estimated at completion

It is likely to go over deadline, 30 May 2008 11:25:28 UTC, but I have read about the deadlines, and am not worried about them, as I understand they are flexible on this project.

Mine finished this morning, just about a couple of hours after deadline:

http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=1144885

Results: http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=3924615


The deadlines are still an issue as it ran in panic mode all the time and prevented me from crunching WU's from other projects. I'll now crunch a few WU's from Seti main and what I might be able to get from LHC, and then I'll come back for more pain here. Ahhhh the bliss of being a tester! Sooo addictive! ;-D

My Athlon XP 2200+ is currently just over 50 hours into a 4.30 WU. It was doing a 4.29, but that crashed last week. 4.30 suspends/resumes OK.

7.797% 24 hrs 307.811
10.000% 30.5 hrs 305.0
15.612% 48 hrs 307.456
16.330% 50 hrs 306.185
16.760% 51.5 hrs 307.279

Those compare to a BOINC Manager estimated time at completion of 316 hours, so progress seems to be fairly linear so far.

Keith.

A minimum host RAC of 150 or 200 (or even 100), would prevent some of the problems.

While also eliminating a lot of potential contributors.

If I look at stderr.txt there are many lines like:

4: s.fbll 262144 c.fbls 262144 s.dcln 3200 s.dcsn 0 s.dn 0 s.dcn 8380416, s.ds 1, l 7

I can see some sort of pattern to these lines of numbers, but I would like to know what they mean. Can anyone point to a page which decodes these?

Keith T.,
that lines of numbers mark certain positions in the code, where values of variables are printed out to debug the source code. The source code is publically available (e.g. link). There is no special page which explains these shortcuts, because they're only of purpose for the developers, they will be left out when these bugs are resolved. (If i'm not totally wrong 's.' means 'state.' and 'c.' means 'client.' and so on. See ap_client_main.cpp for more.)