Binary Radio Pulsar Search (Perseus Arm Survey) "BRP5"
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4332
Credit: 251810059
RAC: 36035
25 Mar 2013 15:19:34 UTC
Topic 196873
(moderation:
The Binary Radio Pulsar Search on Einstein@Home will catch up with the avaliable Arecibo data in about a month. It is estimated that we will then process data from Arecibo roughly at the rate at whic it is taken, which is about 50 beams/d. This will occupy less than a third of our current processing capacity (~160 bemas/d).
We will use the remaining computing power to search for new Radio Pulsars in the data of the Parkes "Perseus Arm Survey", an extension of the "Parkes Multi-Beam Pulsar Survey" (PMPS) along one "arm" of our galaxy.
For this new search will set up (yet) another application (einsteinbinary_BRP5), in parallel to the existing one (einsteinathome_BRP4). The tasks will run about 5h on current GPUs, there will be no CPU version. The application binaries will be the same as the BRP4 ones. We are currently testing the new application over at Albert@Home to determine and adjust runtime estimation, credit, memory footprint etc.
BM
BM
Binary Radio Pulsar Search (Perseus Arm Survey) "BRP5"
)
WOW... 5 hours for 1 task. This sounds interesting. So BM any news when it might be released here at E@H. Also what current GPU's? something like a geforce 550 or newer?
This sounds really interesting but I don't know much about this. So how many "arms" does out galaxy have and which is the starting point?
PC setup MSI-970A-G46 AMD FX-8350 8 core OC'd 4.45GHz 16GB ram PC3-10700 Geforce GTX 650Ti Windows 7 x64 Einstein@Home
RE: So how many "arms" does
)
Have a look at wikipedia for this. There are also entries for each arm.
RE: So BM any news when it
)
On Albert we issued a single beam manually for testing. We are currently setting up a pre-processing pipeline for a continuous supply of workunits to Einstein. As we have a long holiday weekend ahead, I wouldn't expect the first tasks to be sent before mid next week.
We got some more data from Arecibo, the processing of which will take about another month. So we are no longer under so much pressure of running out of data.
I don't know from scratch - whatever is attached to Albert ...
BM
BM
RE: RE: The tasks will
)
GTX550 will be fine (as it works ok on 9600GT, takes about 12h).
RE: RE: The tasks will
)
I did some testing with the new tasks at Albert.
Here are all new tasks i got.
I have a GTX580 and a i7-3770 @ 4.2 GHz. Running a single task took 9100s. Running two took 19000s. So 9500 each. Maybe it took longer because it watched videos, but I will test further when I get new tasks.
RE: RE: RE: The tasks
)
Nice... well I have the geforce 650 Ti so it should be all good. CPU is clocked at 4.4GHz amd 8 core but I only run 4 CPU task and right now 3 GPU task of the BRP4 which each is done around 4,600s. Might have to change down to 2 or even 1 when we get BRP5 here but that's fine by me.
That's all great there for looking at this part of the question but still does not answer where will we start or what is the starting point for us?
PC setup MSI-970A-G46 AMD FX-8350 8 core OC'd 4.45GHz 16GB ram PC3-10700 Geforce GTX 650Ti Windows 7 x64 Einstein@Home
RE: That's all great there
)
I'm not sure I understand this question. The fist set of tasks will be produced from the lexicographically last named dataset of the 50 first pre-processed beams of the first charge of survey data from MPI Bonn that happened to arrive at the AEI. I don't think that this corresponds to any particularly interesting point in the sky.
BM
BM
RE: RE: That's all great
)
Ah ok thanks BM... Yes I was wondering where in the sky was going to be our starting point.
PC setup MSI-970A-G46 AMD FX-8350 8 core OC'd 4.45GHz 16GB ram PC3-10700 Geforce GTX 650Ti Windows 7 x64 Einstein@Home
I assume the current BRP4
)
I assume the current BRP4 CUDA tasks are 3.2. Is there a plan for CUDA 4.2, which should produce better on newer nVidia GPUs?
RE: I assume the current
)
Our BRP application triggers a bug in CUDA versions 4 & 5 that has been reported to NVida. The bug was confirmed but not fixed yet. Until it has, we're stuck with CUDA 3.
BM
BM