Forum > Discussion Forum

Report on new optimized Astropulse apps for Windows

<< < (8/19) > >>

Jason G:
Yes, I'm *attempting* Joe's 'full blank' now.  Don't know if I put it in the right place, We'll see.  I presume it should erase the 30 signals in JasonShort.dat without too much hassle. [If it appears to work I'll post SSE & SSE3 binary for playing with.]

[Later: Looks like 'Scorched earth' here, apart from best pulses all gone.]


--- Code: ---Starting parse: .\testDatas\ref-astropulse_5.00_windows_intelx86.exe-JasonShort.
dat.res
Successfully parsed: .\testDatas\ref-astropulse_5.00_windows_intelx86.exe-JasonS
hort.dat.res
--- Found <ap_signal> tags: 40
Starting parse: .\testDatas\result-ap_5.00r69_SSE3_blankOverride.exe-JasonShort.
dat.res
Successfully parsed: .\testDatas\result-ap_5.00r69_SSE3_blankOverride.exe-JasonS
hort.dat.res
--- Found <ap_signal> tags: 10
Result      : Weakly similar or Different.
--- End code ---

Unfortunately my hack doesn;t write indices.txt, but I do print a line to stderr whenever the randomize_indices() if block executes (stderr attached)

[Pending result from a full WU blank,I'll stop whining about the possibility of artefacts... and start whining about the blanking width instead  :D]


[attachment deleted by admin]

Leaps-from-Shadows:
Update from Cruiser:

First (and last) Astropulse work unit crunched with v4.37 optimized app completed on Main.  Task details.
Credits (759.31) divided by CPU seconds (112876.70) = 0.006726898 credits per CPU second.

Second Astropulse work unit crunched with v5.00 optimized app completed on Beta.  Task details.
Credits (868.56) divided by CPU seconds (89492.05) = 0.009705443 credits per CPU second.

I should have my first v5.00 unit crunched on Main in six hours, plus three more around this time tomorrow (two on Main, one on Beta).

Richard Haselgrove:

--- Quote from: Raistmer on 22 Nov 2008, 05:00:18 am ---@All testers
Please keep eye on indices.txt in working directory (if it become non-zero length or not).
And if you keep result file, please, keep indices.txt too along with result and WU files.
--- End quote ---


--- Quote from: Haselgrove on 22 Nov 2008, 08:52:17 am ---ap_03no08af_B2_P1_00143_20081121_30048 (1065721003)
ap_03no08ag_B2_P1_00100_20081121_20392 (1066329522)

- both just started - have chunky indices.txt files (attached). If I'm reading the guesstimates right, these both have a high chance of pulsing out before their allotted span. Have suspended networking for a result capture.
--- End quote ---


--- Quote from: Josef W. Segur on 22 Nov 2008, 07:16:07 pm ---That second one is a jewel. 2141 blanking indices, leaves about 6422528 samples to process so roughly 81% is blanked. A waste of CPU, but intellectually interesting. If it exits early I suspect the percent blanking reported in the result file won't agree with my calculations, it's done incrementally. In theory it should not be likely to exit early, in practice I'm not even willing to guess.

The indices.txt file isn't used for anything, just written during the initialization step which generates the internal array. It's basically the same information which was put into stderr.txt by the Linux 4.37 stock build, but BOINC will only report the last 64K of stderr. I'm glad they preserved it in this form even if it is ridiculously verbose.
                                                                       Joe

--- End quote ---

Both tasks ran full-length and have now been allowed to report. They both found a limited number of single pulses (4/7 respectively) plus 30 repetitive pulses. I have captured the output files and will upload the 'jewel' (only) to FTP. The other one can stay in cold storage until Jason's mum has got her bandwidth cap removed....

Note for anyone else assisting in this research: the indices.txt file is deleted from the slot directory when the WU finishes processing, whether networking is disabled or not - and of course, a WU can finish early at any moment. Since it's created at the beginning for the run and not changed thereafter, it would be best to copy it to a safe place as soon as the WU starts.

Jason G:
 :'( 30  repetitive pulses in the ~81% blanked task? duh,  I'm just going to take a look and see what I can see... If full-blanked shows a similar pattern we (or the project, rather) has a problem IMO.

Jason G:
Hmmm, arrchive doesn't seem to open.  Any problem during upload (besides speed ?)  LoL ... too quick on the trigger  ;D  I'll wait 'til the upload finishes eh  ;)

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version