The DCF is interesting - but it doesn't address why Astropulse slows down so much when both CPUs run. The slowing down doesn't happen with the normal Seti units and the slowing down doesn't happen when Astropulse is the only @home running.

Take a look at the progress percentage when the time supposedly slows down. It probably progresses at the same rate. That means it's not actually slowing down at all. That's what I've observed on both of my machines anyway.

There's nothing to worry about - and nothing to correct - because the 'to completion' time is inaccurate for all types of SETI units, and always will be.

Edit: It could also be that Astropulse is using the CPU's resources in a different way. If your CPU is a single-core with HT (which means two virtual cores, not a true dual-core), that could be the reason.

---

Cruiser
Gateway GT5692 L-f-S Edition
-Phenom X4 9650 CPU
-4GB 667MHz DDR2 RAM
-500GB SATA HD
-Vista x64 SP1
-BOINC 6.2.19 32-bit client
-SSE3 optimized 32-bit apps

KGK49 - it seems that Astropulse and CPDN running together on an HT P4 doesn't like to play together. See my post over on the BETA boards about it.

---

Wendy



Click Here for BOINC FAQ Service

I agree.I've been using a 400 MHz PII Deschutes on Linux from April 2004 to January 2008 running SETI and Einstein. Now I have an AMD Opteron 1210 at 1.8 GHz, always on Linux, running 6 BOINC projects and I have 10 SETI WUs on pending credit status. It crunched its first Astropulse WU in 115 hours and now has received its second AP with an expected time of 43 hours.
Tullio

Boinc's estimated time may be 43 hours. If the first one took 115 hours, then the expected time is about 115 hours. Astropulse WU's are very consistent - unless they drop out early because too many pulses are found.

F.

You were right, of course. My second AP WU took 115:27:57. I hope I won't have to wait 18 days for my wingmen (two, the first did not make it) to catch up, as happened with my first AP WU.No, this time the wingman was on time.
Tullio

---

KGK49 - it seems that Astropulse and CPDN running together on an HT P4 doesn't like to play together. See my post over on the BETA boards about it.

Web03 - I had read most of the previous posts (looking for info) - but missed the your post (the link you gave). Thanks - I guess no one has looked into the "why" (bottleneck)(math co-processor competion ??) of the slow down - which really isn't all that important since the "quads" are really the machine to have. My point was that it was happening, and if it is more widespread than just a P4 hyperthreading processor that changing the size of the Astropluse calculations might speed things up (reducing/elliminating cache of side 1 and side 2 calculations - and therefore speeding things up).

Leaps-From-Shadows - I tried your idea of looking at the Astopulse percentage done - and with CPDN (or Einstein) running Astropulse percentage slows in concert with the time to completion. I've noticed a group of completion times of about 115 hours - and that's about where I expect to end up. And, my machine is a P4 "hyperthreading" - not a dual-core.

---

Speaking of astropulse.. my custom pc that i built.. that is about 2.5yrs old now.. Originally created as a "competition FPS gaming machine", is able to grind thru AP WU's in just under 85hrs... thats with running an einstine@home and or LHC@home

Astropulse version 4.36 is out since yesterday. http://setiathome.berkeley.edu/apps.php

I'm using a modified app_info.xml, so I can use AK_v8.
Will I get an automatic download of version 4.36?
If not where I can download it?

Astropulse version 4.36 is out since yesterday. http://setiathome.berkeley.edu/apps.php

I'm using a modified app_info.xml, so I can use AK_v8.
Will I get an automatic download of version 4.36? NO
If not where I can download it?

1) Download links for the files:

[Windows]
astropulse_4.36_windows_intelx86.exe (452KB)
ap_graphics_4.36_windows_intelx86.exe (288KB)
libfftw3f-3-1-1a_upx.dll (439KB)

[Linux_32]
astropulse_4.36_i686-pc-linux-gnu (3,088KB)
ap_graphics_4.36_i686-pc-linux-gnu (702KB)

[Linux_64]
astropulse_4.36_x86_64-pc-linux-gnu (3,088KB)
ap_graphics_4.36_x86_64-pc-linux-gnu *

[Common - right-click these files and choose 'Save target as...']
ap436.jpg
astropulse_4.36_AUTHORS
astropulse_4.36_COPYING
astropulse_4.36_COPYRIGHT

* The graphics app for Linux_64 doesn't seem to have been uploaded yet - one tester reported a problem with it. But the link should work when the app is ready.

2) You'll need to update the Astropulse section of your app_info.xml file. Here's a suggestion for Windows:

	<app>
		<name>astropulse</name>
	</app>
	<file_info>
		<name>astropulse_4.36_windows_intelx86.exe</name>
		<executable/>
	</file_info>
	<file_info>
		<name>libfftw3f-3-1-1a_upx.dll</name>
		<executable/>
	</file_info>
	<file_info>
		<name>ap_graphics_4.36_windows_intelx86.exe</name>
		<executable/>
	</file_info>
	<app_version>
		<app_name>astropulse</app_name>
		<version_num>435</version_num>
		<file_ref>
		<file_name>astropulse_4.36_windows_intelx86.exe</file_name>
			<main_program/>
		</file_ref>
		<file_ref>
			<file_name>libfftw3f-3-1-1a_upx.dll</file_name>
		</file_ref>
		<file_ref>
		<file_name>ap_graphics_4.36_windows_intelx86.exe</file_name>
			<open_name>graphics_app</open_name>
		</file_ref>
	</app_version>
	<app_version>
		<app_name>astropulse</app_name>
		<version_num>436</version_num>
		<file_ref>
		<file_name>astropulse_4.36_windows_intelx86.exe</file_name>
			<main_program/>
		</file_ref>
		<file_ref>
			<file_name>libfftw3f-3-1-1a_upx.dll</file_name>
		</file_ref>
		<file_ref>
		<file_name>ap_graphics_4.36_windows_intelx86.exe</file_name>
			<open_name>graphics_app</open_name>
		</file_ref>
	</app_version>

Note that I'm suggesting that you keep a version number 435, to avoid trashing any cached/in progress work already issued: but you change the references in the 435 section to point to the new application. Changing applications in mid-compute hasn't been tested for AP v.35/v.36 yet, but from what we understand of the nature of the change, it shouldn't be a problem. I'll try it myself later this evening.

That app_info.xml fragment I posted earlier seems to be working OK - previously downloaded (branded 4.35) tasks have restarted using 4.36, and newly downloaded tasks are branded 4.36, as expected. Be at least 30 hours before you can check even the first hybrid result on host 4292666, though.

Sorry about the delay in testing - unrelated hard disk problem.

Here is an AstroPulse update suggestion for the section of the app_info.xml file for Linux_32 bit :

<app>
    <name>astropulse</name>
</app>
<file_info>
    <name>astropulse_4.36_i686-pc-linux-gnu</name>
    <executable/>
</file_info>
<file_info>
    <name>ap_graphics_4.36_i686-pc-linux-gnu</name>
    <executable/>
</file_info>
<app_version>
    <app_name>astropulse</app_name>
    <version_num>435</version_num>
    <file_ref>
        <file_name>astropulse_4.36_i686-pc-linux-gnu</file_name>
        <main_program/>
    </file_ref>
    <file_ref>
        <file_name>ap_graphics_4.36_i686-pc-linux-gnu</file_name>
        <open_name>graphics_app</open_name>
    </file_ref>
</app_version>
<app_version>
    <app_name>astropulse</app_name>
    <version_num>436</version_num>
    <file_ref>
        <file_name>astropulse_4.36_i686-pc-linux-gnu</file_name>
        <main_program/>
    </file_ref>
    <file_ref>
        <file_name>ap_graphics_4.36_i686-pc-linux-gnu</file_name>
        <open_name>graphics_app</open_name>
    </file_ref>
</app_version>

---

_\|/_
U r s

Shouldn't be also <version_num>436</version_num> on line 14?

---

Shouldn't be also <version_num>436</version_num> on line 14?

No, Richard Haselgrove answered that in his post 812269 at the very end.

---

_\|/_
U r s

Astropulse version 4.36 is out since yesterday. http://setiathome.berkeley.edu/apps.php

I'm using a modified app_info.xml, so I can use AK_v8.
Will I get an automatic download of version 4.36? NO
If not where I can download it?

1) Download links for the files:

[Windows]
astropulse_4.36_windows_intelx86.exe (452KB)
ap_graphics_4.36_windows_intelx86.exe (288KB)
libfftw3f-3-1-1a_upx.dll (439KB)

[Linux_32]
astropulse_4.36_i686-pc-linux-gnu (3,088KB)
ap_graphics_4.36_i686-pc-linux-gnu (702KB)

[Linux_64]
astropulse_4.36_x86_64-pc-linux-gnu (3,088KB)
ap_graphics_4.36_x86_64-pc-linux-gnu *

[Common - right-click these files and choose 'Save target as...']
ap436.jpg
astropulse_4.36_AUTHORS
astropulse_4.36_COPYING
astropulse_4.36_COPYRIGHT

* The graphics app for Linux_64 doesn't seem to have been uploaded yet - one tester reported a problem with it. But the link should work when the app is ready.

2) You'll need to update the Astropulse section of your app_info.xml file. Here's a suggestion for Windows:

	<app>
		<name>astropulse</name>
	</app>
	<file_info>
		<name>astropulse_4.36_windows_intelx86.exe</name>
		<executable/>
	</file_info>
	<file_info>
		<name>libfftw3f-3-1-1a_upx.dll</name>
		<executable/>
	</file_info>
	<file_info>
		<name>ap_graphics_4.36_windows_intelx86.exe</name>
		<executable/>
	</file_info>
	<app_version>
		<app_name>astropulse</app_name>
		<version_num>435</version_num>
		<file_ref>
		<file_name>astropulse_4.36_windows_intelx86.exe</file_name>
			<main_program/>
		</file_ref>
		<file_ref>
			<file_name>libfftw3f-3-1-1a_upx.dll</file_name>
		</file_ref>
		<file_ref>
		<file_name>ap_graphics_4.36_windows_intelx86.exe</file_name>
			<open_name>graphics_app</open_name>
		</file_ref>
	</app_version>
	<app_version>
		<app_name>astropulse</app_name>
		<version_num>436</version_num>
		<file_ref>
		<file_name>astropulse_4.36_windows_intelx86.exe</file_name>
			<main_program/>
		</file_ref>
		<file_ref>
			<file_name>libfftw3f-3-1-1a_upx.dll</file_name>
		</file_ref>
		<file_ref>
		<file_name>ap_graphics_4.36_windows_intelx86.exe</file_name>
			<open_name>graphics_app</open_name>
		</file_ref>
	</app_version>

Note that I'm suggesting that you keep a version number 435, to avoid trashing any cached/in progress work already issued: but you change the references in the 435 section to point to the new application. Changing applications in mid-compute hasn't been tested for AP v.35/v.36 yet, but from what we understand of the nature of the change, it shouldn't be a problem. I'll try it myself later this evening.

I got an error when trying to use the 4.36 on an in cache WU that hadn't started yet. It errored out on startup of the WU. Could be my edit so I'm looking it over now.

---

Ok, so I'm going back to 4.35 till someone can let me know what's wrong with my app info file
At first I thought things weren't working because the file size for the app wasn't the right size so I had to download it a couple of times to get it to the right size. Had a similar problem when I first did 4.35. That seemed to cause more problems I don't understand and ended up losing all my cache. But it didn't get reported, just gone. Here's an example of some of the text.

26-Sep-2008 18:53:20 [SETI@home] [error] State file error: missing application setiathome_enhanced
26-Sep-2008 18:53:20 [SETI@home] [error] Can't handle workunit in state file
26-Sep-2008 18:53:20 [SETI@home] [error] State file error: missing application setiathome_enhanced
26-Sep-2008 18:53:20 [SETI@home] [error] Can't handle workunit in state file
26-Sep-2008 18:53:20 [SETI@home] [error] State file error: missing task 23au08aa.13562.6617.15.8.133
26-Sep-2008 18:53:20 [SETI@home] [error] Can't link task 23au08aa.13562.6617.15.8.133_0 in state file
26-Sep-2008 18:53:20 [SETI@home] [error] State file error: missing task 23au08aa.13562.20523.15.8.220
26-Sep-2008 18:53:20 [SETI@home] [error] Can't link task 23au08aa.13562.20523.15.8.220_0 in state file
26-Sep-2008 18:53:20 [SETI@home] [error] State file error: missing task 28au08ab.22328.12342.16.8.197
26-Sep-2008 18:53:20 [SETI@home] [error] Can't link task 28au08ab.22328.12342.16.8.197_1 in state file
26-Sep-2008 18:53:20 [SETI@home] [error] State file error: missing task 21au08ae.2717.2935.11.8.123
26-Sep-2008 18:53:20 [SETI@home] [error] Can't link task 21au08ae.2717.2935.11.8.123_0 in state file
26-Sep-2008 18:53:20 [SETI@home] [error] State file error: missing task 21au08af.11755.9070.9.8.208

Anyway, I'm getting back to 435 for now.

---

Those are all errors relating to the setiathome_enhanced sections of app_info.xml - nothing to do with the Astropulse bit or version.

The file you posted is missing the <app_info> tag, which should be on a line by itself at the beginning.

Tip: It's much easier to check for mis-matched tags like that if you use indenting to show the tag level visually. All my samples use indenting, but owing to the b******d format display here, you don't see it. If you click 'quote' under my message 812269, you can copy the formatted version from the edit box (but please don't actually post the quote back into this forum - two copies is quite enough already, thank you!).

Those are all errors relating to the setiathome_enhanced sections of app_info.xml - nothing to do with the Astropulse bit or version.

The file you posted is missing the <app_info> tag, which should be on a line by itself at the beginning.

Tip: It's much easier to check for mis-matched tags like that if you use indenting to show the tag level visually. All my samples use indenting, but owing to the b******d format display here, you don't see it. If you click 'quote' under my message 812269, you can copy the formatted version from the edit box (but please don't actually post the quote back into this forum - two copies is quite enough already, thank you!).

I did go in thru quote to get your copy the first time, but I'll try that again. thanks. I know the errors listed earlier by me had to do with the setiahome project, but at the point these were made nothing to do with seti on the info file had been changed and the seti (AK V8) part was working. It wasn't until I downloaded the exe file of 4.36 into the seti folder a couple of times to get it to the right size that this happended, which is why I was so surprised about it. At no point of my trying to get 4.36 to work did I change anything to do with AK V8, and I'm still lost as to how downloading a file into the seti folder would effect that part of the app info file. BTW another thing that seemed to happen when I put the 4.36 version in my seti folder, the 4.35 exe ended up missing. Also when I did get the Seti errors The Ak V8 exe app was gone too. Neither of these were deleted by me.

Also curious if you did the test last night and were able to use 4.36 on an AP WU that had already started or do I need to wait for the AP's that are in cache to finish before I try the edit again?

Oh and sorry about posting the quote on the earlier one, I thought I'd hit reply, and once I posted it got distracted with something else. By the time I got back to the post the edit feature was gone so I couldn't take it out. MY BAD.

---

Also curious if you did the test last night and were able to use 4.36 or an AP WU that had already started or do I need to wait for the AP's that are in cache to finish before I try the edit again?

Yes I did test, and it worked - see message 812407.

Your problem will have been the missing first line <app_info> tag: without that, it doesn't know what to do with the rest of it. You've probably got a whole lot of messages about 'unparsed' this and that in your message log archive.

Also curious if you did the test last night and were able to use 4.36 or an AP WU that had already started or do I need to wait for the AP's that are in cache to finish before I try the edit again?

Yes I did test, and it worked - see message 812407.

Your problem will have been the missing first line <app_info> tag: without that, it doesn't know what to do with the rest of it. You've probably got a whole lot of messages about 'unparsed' this and that in your message log archive.

Ok, thanks I'll look at my edit again before I try. The log only refers to the errors, nothing about anything being unparsed. The cache got emptied because I assume once the AK V8 exe ended up out of the folder, BOINC had nothing to work with. The log shows BOINC finding the app info file and then all hell breaking lose with bad application errors, can't handle state file, etc.. Once I put the AK V8 back in the folder that part worked again.

---

Now one other question bout all this that is seperate from what's being discussed here but since it's all documented here I'll ask in this thread. I have 20 something WU's floating out there, no longer on my pc, becuase of this error that wingmen will be forced to wait on. I'm guessing I have to detach once I end the last two WU's on my machine and that will release those other WU that got emptied from my cache?

---

Now one other question bout all this that is seperate from what's being discussed here but since it's all documented here I'll ask in this thread. I have 20 something WU's floating out there, no longer on my pc, becuase of this error that wingmen will be forced to wait on. I'm guessing I have to detach once I end the last two WU's on my machine and that will release those other WU that got emptied from my cache?

That seems to be the general consensus, if there are still tasks for the host shown as "In progress" on this website. If they've already been reported as "Compute error", there's no need to do anything else.

Note that detaching and re-attaching will delete everything from the project folder (again!). Make sure you have a convenient backup of your AK_V8 applications and support files, your Astropulse applications and support files, and your spliced (and topped and tailed) app_info.xml file.

I detached and it didn't clear up most the WU's that got deleted from my system ( only appears at the moment 2 out of 20 something show client detached ) so I'm now at a loss as to what I can do to free them from my task list. I'm going to re-attach the project now and go back to crunching.

---