Task ID 945888297
Name ap_04jl08aa_B6_P1_00079_20080807_20336.wu_1
Workunit 312521251

<snip>

120 odd hours for nothing. Until astropulse is sorted it will be aborted on my comps. Dayoff

That looks like a validator problem. Your wingman found 30 pulses after dm_chunk_large 2944, and bailed out early: you went on the complete the full search.

That should result in status 'Checked, but no consensus yet', and both credit claims kept 'pending' until the third result (which has been correctly generated) is returned for comparison.

The developers will be interested in your report, and may be able to grant credit manually (there are precedents). If they do, I hope you'll reconsider your policy of aborting all AP tasks on sight: it's only through experiences, and reports, like yours that the final problems will be ironed out of the Astropulse application and back-end processes.

Hi, followed this thread and think, that this is probably also a way to 'see', how the AP units 'behave'and if there are errors, wich kind are they and differences in validating can also be ajusted, but 'they' need to have some valid results, with a credit claim[/] to get the [i]validators to work OK.
I do hope, that they get validated, I do have completed 7 off them, considering 24 hours to complete, means, on a QUAD, 2 day's and 7 x 720= 5040 credits, 2520 a day. That is quite common, compaired by SETI MB without OptiApp.

---

Looks like you got bitten by the same bug as me, I lost an AP unit as well when it was suspended.

Try turning on the "Leave Application in Memory" option.

My first Astropulse unit has just crashed too. Intel Mac. Task result

As with others below (or above, depending which way you like your threads), I had suspended it while running other things and it crashed immediately upon resumption.

When I have used 'Leave Application in Memory' in the past, I have had trouble with tasks not releasing the CPU and seeming to get stuck in a full power loop, busily calculating nothing. Task progress was not incrementing but Hardware Monitor showed the processor(s) still steaming away at 100%.

I think I'll wait until a real fix is forthcoming.

Well I am having fun watching my second Astropulse run.
#ap_06fe08ac_B0_P1_00324_20080813_29361.wu_0
Original CPU estimate was 142 hours.
Currently 61 hours complete, progress is 20.497% and CPU estimate to completion is now another 146 hours.
Interesting, so I will let it finish and have another completed AP unit for discussion purposes.
I run with "leave app in memory" and have my second CPU crunching at the moment.
When the second CPU finishes crunching its units, I will watch the time estimates to see if there is a significant change in the AP unit.

Running on an AuthenticAMD AMD Turion(tm) 64 X2 Mobile Technology TL-58 [x86 Family 15 Model 104 Stepping 1] with Microsoft Windows Vista
Home Premium x86 Editon

Update:
75:25 hours running
25.288% progress complete
141:24 left to completion

Update 2:
87:10 hours running
29.000% progress complete
137:51 left to completion

Update 3:
109:00 hours running
38.855% progress complete
118:26 left to completion

Looks like you got bitten by the same bug as me, I lost an AP unit as well when it was suspended.

Try turning on the "Leave Application in Memory" option.

My first Astropulse unit has just crashed too. Intel Mac. Task result

As with others below (or above, depending which way you like your threads), I had suspended it while running other things and it crashed immediately upon resumption.

When I have used 'Leave Application in Memory' in the past, I have had trouble with tasks not releasing the CPU and seeming to get stuck in a full power loop, busily calculating nothing. Task progress was not incrementing but Hardware Monitor showed the processor(s) still steaming away at 100%.

I think I'll wait until a real fix is forthcoming.

Well I am having fun watching my second Astropulse run.
#ap_06fe08ac_B0_P1_00324_20080813_29361.wu_0
Original CPU estimate was 142 hours.
Currently 61 hours complete, progress is 20.497% and CPU estimate to completion is now another 146 hours.
Interesting, so I will let it finish and have another completed AP unit for discussion purposes.
I run with "leave app in memory" and have my second CPU crunching at the moment.
When the second CPU finishes crunching its units, I will watch the time estimates to see if there is a significant change in the AP unit.

Running on an AuthenticAMD AMD Turion(tm) 64 X2 Mobile Technology TL-58 [x86 Family 15 Model 104 Stepping 1] with Microsoft Windows Vista
Home Premium x86 Editon

Update:
75:25 hours running
25.288% progress complete
141:24 left to completion

Update 2:
87:10 hours running
29.000% progress complete
137:51 left to completion

Update 3:
109:00 hours running
38.855% progress complete
118:26 left to completion

Okay... I don't see how the numbers are changing... it's going to take you ~300 CPU hours to complete. About 6 more days... post every day if you wish, but this is the fact and we have already been there... Astropulse underclaims credits and does not estimate the correct CPU time.

Welcome to the club!

Good night,
JDWhale

---

Looks like you got bitten by the same bug as me, I lost an AP unit as well when it was suspended.

Try turning on the "Leave Application in Memory" option.

My first Astropulse unit has just crashed too. Intel Mac. Task result

As with others below (or above, depending which way you like your threads), I had suspended it while running other things and it crashed immediately upon resumption.

When I have used 'Leave Application in Memory' in the past, I have had trouble with tasks not releasing the CPU and seeming to get stuck in a full power loop, busily calculating nothing. Task progress was not incrementing but Hardware Monitor showed the processor(s) still steaming away at 100%.

I think I'll wait until a real fix is forthcoming.

Well I am having fun watching my second Astropulse run.
#ap_06fe08ac_B0_P1_00324_20080813_29361.wu_0
Original CPU estimate was 142 hours.
Currently 61 hours complete, progress is 20.497% and CPU estimate to completion is now another 146 hours.
Interesting, so I will let it finish and have another completed AP unit for discussion purposes.
I run with "leave app in memory" and have my second CPU crunching at the moment.
When the second CPU finishes crunching its units, I will watch the time estimates to see if there is a significant change in the AP unit.

Running on an AuthenticAMD AMD Turion(tm) 64 X2 Mobile Technology TL-58 [x86 Family 15 Model 104 Stepping 1] with Microsoft Windows Vista
Home Premium x86 Editon

Update:
75:25 hours running
25.288% progress complete
141:24 left to completion

Update 2:
87:10 hours running
29.000% progress complete
137:51 left to completion

Update 3:
109:00 hours running
38.855% progress complete
118:26 left to completion

Okay... I don't see how the numbers are changing... it's going to take you ~300 CPU hours to complete. About 6 more days... post every day if you wish, but this is the fact and we have already been there... Astropulse underclaims credits and does not estimate the correct CPU time.

Welcome to the club!

Good night,
JDWhale

Update 4:
Halfway point?
112:43 hours running
41.730% progress complete
112:43 left to completion
We don't need to be a math major to know 42% in not half.
I will presume that the early crunching is more processor intensive.
I have noticed that the completion time is finally starting to drop 1 second for every 1 CPU second. Early on, the completion time would not budge for 10 CPU seconds, and sometimes actually go backwards.

Heck of a club we joined eh.
Dave

...

Update 4:
Halfway point?
112:43 hours running
41.730% progress complete
112:43 left to completion
We don't need to be a math major to know 42% in not half.
I will presume that the early crunching is more processor intensive.
I have noticed that the completion time is finally starting to drop 1 second for every 1 CPU second. Early on, the completion time would not budge for 10 CPU seconds, and sometimes actually go backwards.

Heck of a club we joined eh.
Dave

BoincLogX can give you a more accurate estimate.

There has been much discussion of this issue on the "Message boards : AstroPulse" forum at SETI Beta

---

Sir Arthur C Clarke 1917-2008

Update 4:
Halfway point?
112:43 hours running
41.730% progress complete
112:43 left to completion
We don't need to be a math major to know 42% in not half.
I will presume that the early crunching is more processor intensive.
I have noticed that the completion time is finally starting to drop 1 second for every 1 CPU second. Early on, the completion time would not budge for 10 CPU seconds, and sometimes actually go backwards.

Heck of a club we joined eh.
Dave

I've done a couple of AP now. running it along side other SETI and Einstein work units it took about 108 actual hours and a CPU time (sec) 236,455.40 throttled at 75% cpu time.

The other one I ran buy itself and took about 60 actual hours and had a CPU time (sec) 209,267.00 100% cpu time.

In both units the time was always running down, just slower at different times and they were both quoted in about the 37 hour range. I was told to expect double which I assumed meant the cpu time and not the actual time, so it ran about what was expected as far as I can see.

---

Okay, i've turned the over clock off and going to try astro at stock speed, have just got some so let see.

---

The requirements for Astropulse are supposed to be a 1.6ghz cpu minimum. One was sent to my old Compaq Pentium III 1ghz laptop and several were sent to a dual Pentium III 1.1ghz machine. The laptop crunched about 60 hours and was 4 percent complete when I cancelled it. I just downloaded the latest BOINC to see if I can deselect Astro.

Bob B.

---

Well the strangest thing just happened.

Leaving them in memory doesn't stop the errors on Mac's. I had seven tasks Ap tasks running. I have had to restart the machine. Now six stopped with compute errors, yet the seventh is still going strong as I type this.

Although dotsch has done a great job getting a Mac app that can work, I don't think those of us with macs should be running Ap until the project release an official app.

---

The requirements for Astropulse are supposed to be a 1.6ghz cpu minimum. One was sent to my old Compaq Pentium III 1ghz laptop and several were sent to a dual Pentium III 1.1ghz machine. The laptop crunched about 60 hours and was 4 percent complete when I cancelled it. I just downloaded the latest BOINC to see if I can deselect Astro.

Bob B.

The option to deselect AP is on your Account page under Seti@Home preferences. There is no need to change/upgrade BOINC.

<core_client_version>6.2.18</core_client_version>
<![CDATA[
<message>
process exited with code 193 (0xc1, -63)
</message>
<stderr_txt>
In ap_gfx_main.cpp: in ap_graphics_init(): Starting client.
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 896
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 1024
In ap_gfx_main.cpp: in ap_graphics_init(): Starting client.
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 1024
In ap_gfx_main.cpp: in ap_graphics_init(): Starting client.
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 1024
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 1152
In ap_gfx_main.cpp: in ap_graphics_init(): Starting client.
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 1152
In ap_gfx_main.cpp: in ap_graphics_init(): Starting client.
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 1152
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 1280
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 1408
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 1536
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 1664
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 1792
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 1920
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 2048
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 2176
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 2304
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 2432
In ap_gfx_main.cpp: in ap_graphics_init(): Starting client.
terminate called after throwing an instance of 'std::bad_alloc'
what(): St9bad_alloc
SIGABRT: abort called

Crashed executable name: astropulse_4.35_i686-apple-darwin
Machine type Intel 80486 (32-bit executable)
System version: Macintosh OS 10.5.4 build 9E17
Mon Aug 25 22:50:02 2008

sh: /usr/bin/atos: No such file or directory
0 0x0004e931 1 0x00042f12 2 0x95a6a09b 3 0xffffffff 4 0x95ae2ec2 5 0x95af247f 6 0x92bc1005 7 0x92bbf10c 8 0x92bbf14b 9 0x92bbf261 10 0x92bbf5d8 11 0x00026fe3 12 0x00028837 13 0x0002bd55 14 0x0002cf49 15 0x000185bf 16 0x0003a9f4 17 0x00037e76 18 0x00031421 19 0x00034768 20 0x00002736
Thread 0 crashed with X86 Thread State (32-bit):
eax: 0xffffffe1 ebx: 0x95a31e62 ecx: 0xbfffd2ac edx: 0x959fd4a6
edi: 0x00000000 esi: 0x00000000 ebp: 0xbfffd2e8 esp: 0xbfffd2ac
ss: 0x0000001f efl: 0x00000206 eip: 0x959fd4a6 cs: 0x00000007
ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037

Binary Images Description:
0x1000 - 0xeafff /Library/Application Support/BOINC Data/slots/2/../../projects/setiathome.berkeley.edu/astropulse_4.35_i686-apple-darwin
0x9126d000 - 0x91271fff /usr/lib/system/libmathCommon.A.dylib
0x92b79000 - 0x92bd6fff /usr/lib/libstdc++.6.dylib
0x93b78000 - 0x93b7ffff /usr/lib/libgcc_s.1.dylib
0x959fc000 - 0x95b5cfff /usr/lib/libSystem.B.dylib


Exiting...

</stderr_txt>
]]>

Just wasted another 6 hours of CPU time

---

Looks like you got bitten by the same bug as me, I lost an AP unit as well when it was suspended.

Try turning on the "Leave Application in Memory" option.

My first Astropulse unit has just crashed too. Intel Mac. Task result

As with others below (or above, depending which way you like your threads), I had suspended it while running other things and it crashed immediately upon resumption.

When I have used 'Leave Application in Memory' in the past, I have had trouble with tasks not releasing the CPU and seeming to get stuck in a full power loop, busily calculating nothing. Task progress was not incrementing but Hardware Monitor showed the processor(s) still steaming away at 100%.

I think I'll wait until a real fix is forthcoming.

Well I am having fun watching my second Astropulse run.
#ap_06fe08ac_B0_P1_00324_20080813_29361.wu_0
Original CPU estimate was 142 hours.
Currently 61 hours complete, progress is 20.497% and CPU estimate to completion is now another 146 hours.
Interesting, so I will let it finish and have another completed AP unit for discussion purposes.
I run with "leave app in memory" and have my second CPU crunching at the moment.
When the second CPU finishes crunching its units, I will watch the time estimates to see if there is a significant change in the AP unit.

Running on an AuthenticAMD AMD Turion(tm) 64 X2 Mobile Technology TL-58 [x86 Family 15 Model 104 Stepping 1] with Microsoft Windows Vista
Home Premium x86 Editon

Update:
75:25 hours running
25.288% progress complete
141:24 left to completion

Update 2:
87:10 hours running
29.000% progress complete
137:51 left to completion

Update 3:
109:00 hours running
38.855% progress complete
118:26 left to completion

Okay... I don't see how the numbers are changing... it's going to take you ~300 CPU hours to complete. About 6 more days... post every day if you wish, but this is the fact and we have already been there... Astropulse underclaims credits and does not estimate the correct CPU time.

Welcome to the club!

Good night,
JDWhale

Update 4:
Halfway point?
112:43 hours running
41.730% progress complete
112:43 left to completion
We don't need to be a math major to know 42% in not half.
I will presume that the early crunching is more processor intensive.
I have noticed that the completion time is finally starting to drop 1 second for every 1 CPU second. Early on, the completion time would not budge for 10 CPU seconds, and sometimes actually go backwards.

Heck of a club we joined eh.
Dave

Update 5:
Ok we are over halfway there!
126:12 hours running
50.470% progress complete
92.41 left to go
Completion time is definitely speeding up, and I am still crunching on my other CPU.
Interesting posts about the MACS. Sounds like I would wait it out too if I used one for crunching AP's. Then again, mine is not finished either.

[quote]Looks like you got bitten by the same bug as me, I lost an AP unit as well when it was suspended.

Try turning on the "Leave Application in Memory" option.

My first Astropulse unit has just crashed too. Intel Mac. Task result

As with others below (or above, depending which way you like your threads), I had suspended it while running other things and it crashed immediately upon resumption.

When I have used 'Leave Application in Memory' in the past, I have had trouble with tasks not releasing the CPU and seeming to get stuck in a full power loop, busily calculating nothing. Task progress was not incrementing but Hardware Monitor showed the processor(s) still steaming away at 100%.

I think I'll wait until a real fix is forthcoming.

Well I am having fun watching my second Astropulse run.
#ap_06fe08ac_B0_P1_00324_20080813_29361.wu_0
Original CPU estimate was 142 hours.
Currently 61 hours complete, progress is 20.497% and CPU estimate to completion is now another 146 hours.
Interesting, so I will let it finish and have another completed AP unit for discussion purposes.
I run with "leave app in memory" and have my second CPU crunching at the moment.
When the second CPU finishes crunching its units, I will watch the time estimates to see if there is a significant change in the AP unit.

Running on an AuthenticAMD AMD Turion(tm) 64 X2 Mobile Technology TL-58 [x86 Family 15 Model 104 Stepping 1] with Microsoft Windows Vista
Home Premium x86 Editon

Update:
75:25 hours running
25.288% progress complete
141:24 left to completion

Update 2:
87:10 hours running
29.000% progress complete
137:51 left to completion

Update 3:
109:00 hours running
38.855% progress complete
118:26 left to completion

Okay... I don't see how the numbers are changing... it's going to take you ~300 CPU hours to complete. About 6 more days... post every day if you wish, but this is the fact and we have already been there... Astropulse underclaims credits and does not estimate the correct CPU time.

Welcome to the club!

Good night,
JDWhale

Update 4:
Halfway point?
112:43 hours running
41.730% progress complete
112:43 left to completion
We don't need to be a math major to know 42% in not half.
I will presume that the early crunching is more processor intensive.
I have noticed that the completion time is finally starting to drop 1 second for every 1 CPU second. Early on, the completion time would not budge for 10 CPU seconds, and sometimes actually go backwards.

Heck of a club we joined eh.
Dave

Update 5:
Ok we are over halfway there!
126:12 hours running
50.470% progress complete
92.41 left to go
Completion time is definitely speeding up, and I am still crunching on my other CPU.
Interesting posts about the MACS. Sounds like I would wait it out too if I used one for crunching AP's. Then again, mine is not finished either.

Last update:
CRASH and BURN
8/26/2008 2:23:06 PM|SETI@home|Task ap_06fe08ac_B0_P1_00324_20080813_29361.wu_0 exited with zero status but no 'finished' file
8/26/2008 2:23:06 PM|SETI@home|If this happens repeatedly you may need to reset the project.
8/26/2008 2:23:06 PM|SETI@home|Restarting task ap_06fe08ac_B0_P1_00324_20080813_29361.wu_0 using astropulse version 435
143:16 hours running
1.852% progress complete
244:38 left to go

Not sure what happened guys, but I won't continue to use this PC for AP's at this rate.

I wondered, after the third ERROR MESSAGE FROM MICROSOFT, stating that the x86 APx86 xxxxx client, has to be shut down, why there' s a X64 version for LINUX, but NOT for Windows.
Since a run WIN XP64 on that host. Win XP64, has a 32BIT subsystem, wich works OK.
Maybe 1 x86 and 1 X64 app. is a bad combination for WIN XP64.
I NEVER saw these error's, before.
Since yesterday I lost a few AP WU's, after 1 till 28 hours, after erroring out, kind off a waist off time.
AP WU

---

After a full CPU, FPU, CPU-Intercore, CPU-Cache, Memory test(SiSoftSandra), couldn't find a single error.
I DID lower the OC a bit, don't know what's causing the errors.
Have to open a WEB-Site, for showing some results off the test's.

---

Any ideas as to why this AP unit died? 311871013
When it died my computer said it was low on virtual memory.

Thanks

---

<core_client_version>5.10.39</core_client_version>
<![CDATA[
<message>
process exited with code 193 (0xc1, -63)
</message>
<stderr_txt>
Unrecognized XML in parse_init_data_file: fraction_done_update_period
Skipping: 1.000000
Skipping: /fraction_done_update_period
In ap_gfx_main.cpp: in ap_graphics_init(): Starting client.
Unrecognized XML in parse_init_data_file: fraction_done_update_period
Skipping: 1.000000
Skipping: /fraction_done_update_period
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 896
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 1024
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 1152
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 1280
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 1408
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 1536
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 1664
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 1792
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 1920
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 2048
Unrecognized XML in parse_init_data_file: fraction_done_update_period
Skipping: 1.000000
Skipping: /fraction_done_update_period
In ap_gfx_main.cpp: in ap_graphics_init(): Starting client.
Unrecognized XML in parse_init_data_file: fraction_done_update_period
Skipping: 1.000000
Skipping: /fraction_done_update_period
terminate called after throwing an instance of 'std::bad_alloc'
what(): St9bad_alloc
SIGABRT: abort called

Crashed executable name: astropulse_4.35_i686-apple-darwin
Machine type Intel 80486 (32-bit executable)
System version: Macintosh OS 10.5.1 build 9B18
Wed Aug 27 02:48:41 2008

sh: /usr/bin/atos: No such file or directory
0 0x0004e931 1 0x00042f12 2 0x90fb697b 3 0xffffffff 4 0x9102f782 5 0x9103ed3f 6 0x9053b005 7 0x9053910c 8 0x9053914b 9 0x90539261 10 0x905395d8 11 0x00026fe3 12 0x00028837 13 0x0002bd55 14 0x0002cf49 15 0x000185bf 16 0x0003a9f4 17 0x00037e76 18 0x00031421 19 0x00034768 20 0x00002736 21 0x00000001
Thread 0 crashed with X86 Thread State (32-bit):
eax: 0xffffffe1 ebx: 0x90f7e7e2 ecx: 0xbfffcf1c edx: 0x90f4a8e6
edi: 0x00000000 esi: 0x00000000 ebp: 0xbfffcf58 esp: 0xbfffcf1c
ss: 0x0000001f efl: 0x00000206 eip: 0x90f4a8e6 cs: 0x00000007
ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037

Binary Images Description:
0x1000 - 0xeafff /Library/Application Support/BOINC Data/slots/1/../../projects/setiathome.berkeley.edu/astropulse_4.35_i686-apple-darwin
0x904f3000 - 0x90550fff /usr/lib/libstdc++.6.dylib
0x90f4a000 - 0x910a4fff /usr/lib/libSystem.B.dylib
0x9271f000 - 0x92726fff /usr/lib/libgcc_s.1.dylib
0x93a4e000 - 0x93a4ffff /usr/lib/system/libmathCommon.A.dylib


Exiting...

</stderr_txt>




Another error on Mac Pro after processing a bunch of shorties and couple of restarts.
Is that coincidense that no official Mac version of Astropulse is available?

---

I wonder if we'll ever see an official release for the Mac.

---

ORPHANED AstroPulse Work Units

I was just reviewing my current TASKS in my account and spotted two AstroPulse WUs assigned to me:

Task ID WUnit ID Sent Deadline
944674187 311943043 6 Aug 2008 17:52:05 UTC 5 Sep 2008 17:52:05 UTC In progress --- New --- --- ---
940308992 309881827 3 Aug 2008 16:34:54 UTC 2 Sep 2008 16:34:54 UTC In progress --- New --- --- ---

HOWEVER:
(1) neither appears in BOINC Manager (v6.2.18) tasks;
(2) I didn't download AP client (4.35) nor modify my app_info.xml file until ~26Aug08;
(3) I didn't modify my S@H Computing Preferences prior to Ageless's AstroPulse FAQ posting http://setiathome.berkeley.edu/forum_thread.php?id=48489&nowrap=true#797712 on 14Aug. I did notice though at that time that both Seti MultiBeam and AstroPulse were enabled (by default, I guess) in my S@H Prefs;
(4) I did see, but don't remember if might have occurred on 3Aug and/or 6Aug or both, that BOINC Manager Message log recorded that Seti did ask to send me 1 or 2 (?) AP workunits, but didn't because BOINC sensed I had no comaptible application installed.

<b>Can I (or someone in Berkeley) "cancel" my assignment to those 2 AP units and instead send them to someone else now so as not to strand my wingmen??</b>

BTW: I installed AP client v4.35 & modded the app_info.xml file, set S@H Prefs to AP only, and got 2 AP WUs on 27Aug. One AP WU completed this morning (66,585 CPU secs, 454 credits claimed+granted), the 2nd AP WU is still crunching (currently at 67.8% after 20h:45m with estimated 08h:35m to reach completion).

---

Sabertooth Z77, i7-3770K@4.2GHz, GTX680, W8.1Pro x64
P5N32-E SLI, C2D E8400@3Ghz, GTX580, Win7SP1Pro x64 & PCLinuxOS2015 x64

To make DCF work as well as it can, the project needs to get the raw estimates for all work in line. From reported data here it looks like the AP estimate needs to be scaled up, but the most that can be expected is scaling to approximately match stock setiathome_enhanced. Those running optimized s_e will continue to have a significant mismatch unless optimized versions of AstroPulse can be produced which achieve similar speed improvements.

All you can do is calibrate the scaling to the stock apps. The guys running optimized apps should be smart enough to know the est. completion times will be off. :)

That said, my 1st AP WU since reattaching to SETI says it will take 92 hours on a 3.0GHz E8400. That seems a bit high compared to the others on the forum. I'll wait until it reports OK before talking anymore about this.

I got my first 2 AP WUs on 27Aug., I'm crunching them using the standard v4.35 AP client. Both AP WUs started with an estimated completion time of 13h:00m, and the est. completion time continued to increase (not decrease) during about the first 12 hours of computation, then levelled off and began to slowly decrease. One AP WU completed this morning (66,585 CPU secs, 454 credits claimed+granted), the 2nd AP WU is still crunching (currently at 70.0% after 21h:20m with estimated 08h:05m to reach completion).

For non-AP WUs, I crunch using Alex Kan's v8 SSE4.1 optimized client. With my C2D E8400, I can crank out ~1 MB WU/core/hr, hence ~2 WUs/hour. Most recent typical MB WUs completed in average ~4200 CPU secs and yield average 52 credits.

So it seems, at least for me + my wingman, the 454 credit granted for this first completed AP is quite LOW (this WU took 66,585 CPU secs on my E8400 under WinXP32SP3, less than my wingman's 69,814 CPU sec under VistaSP1). To be on rough parity w/ MB, the AP should have granted 66.6/4.2 * 52 = 817 credits -vs- the actual claimed+granted 454 credits. Maybe my math is invalid trying to compare time+credit of non-optimized AP client -vs- AKv8 optimized MB client. Granted that was my first completed AP WU, hopefully future AP WUs will yield more credit. I do S@H for the science, but it *is* nice to earn some credits whilst we're at it.

---

Sabertooth Z77, i7-3770K@4.2GHz, GTX680, W8.1Pro x64
P5N32-E SLI, C2D E8400@3Ghz, GTX580, Win7SP1Pro x64 & PCLinuxOS2015 x64