I would guess that the change was only recently devised.

Not quite. Initial Joe's BLANKIT mod was introduced quite long time ago.
Need to keep telling that currently SETI@home is purely volunteered endeavor, I would say from Berkeley's side too, not only from our. What it means?
It means that despite of string on the bottom of beta forum pages SETI team has no funds from US government long ago already. Also that means that all team members can't dedicate long enough time quanta for SETI development, even day to day support severely deteriorated by non-SETI constant activity requirement.
All this incurs long delays in everything we do here. In each step.
Nobody can allow himself to live w/o money in this mad world...

I'm probably going to stir up a hornet's nest with this but.....
I actually don't mind too much (outside of the WOW challenge) when I get work units that eventually get highly blanked. Why, you ask? After all the reading the discussions on just what is going on when the data gets analyzed, I came to appreciate just what is going on. There is talk that v7 "will fix" the blanking problem. Well, not really. It actually just "replaces" the problem. I understand why it is being done. But sacrificing sensitivity for improve specificity leaves a lot of potential signals out of the mix. I know I'm late to the party on this and v7 is well underway in testing in Beta. I guess it just rubs me wrong way when someone says that v7 "fixes" the problem. It doesn't fix it, rather to try to find a signal in a mess of noise, it replaces that entire area with a blanket noise that easier to skip over. I really appreciate all the effort and time that has being put in over the years by everyone that has worked on this project. It's not easy to find people willing to donate their time and expertise in helping this project. I guess I posted this just so people are aware that in order to get a "Faster" AP we do so with the knowledge that might be "throwing out the baby with the bath water." Just my 2 pesos...lol

Zalster

Analysis of AP data for single pulses is done on data chunks of 32K sequential samples (13.1072 milliseconds at 2.5 MHz. sample rate). For v5 and v6 if blanking was needed the 32K samples were replaced by pseudorandom data which was then dedispersed and analyzed for signals as if it was real data. The pseudorandom data was shaped to fit the frequency characteristics of good data from the same task, but still it was totally artificial and searching it for signals was putting bogus "found" signals into the science database. The fundamental change in v7 is to simply not do single pulse analysis of bad data chunks. The side effect of not needing the CPU intensive generation of that blanking data is a bonus. There is no loss of sensitivity, though not reporting bogus "found" signals will reduce the number of signals going into the science database.

For repetitive pulse processing, each data chunk supplies a bandwidth reduced sequence of 1024 samples for the short period analysis or 128 samples for the longer period. For blanked chunks, whether those samples are derived from pseudorandom noise or are idealized to the proper average level makes little scientific difference. I expect the v7 method to generally find fewer repetitive pulses in heavily blanked tasks, but that makes sense when there's less real data. Individual tasks may be exceptions, we have one 61% blanked test task which finds 0 repetitive signals when processed by v6 but finds 9 when processed by v7.

There are aspects of how blanking is implemented which might possibly be considered "throwing out the baby with the bath water". For instance, the detection of excess RFI identifies positions tightly but the application blanks all data chunks for 0.16 seconds before and after those detection points. I don't know enough about the ALFA receiver system to judge with any certainty, but I suspect at least the blanking before detection points could be shortened a lot.

                                                                  Joe

Thanks TBar,
I just did that. Only one question thereto: If I have a 4 core 8 thread system, does that mean that I have to let one thread held as idle for each gpu that I have? In my 2 gpu setup that means I have to put 75% in "use at most" computer preferences. If that is the case it seems as though I would be putting quite a bit of power in an idle state. Right?

For now you can just alter the app_config file to run one at a time with 1 CPU core reserved. Hal's example will work for that;

<app_config>
	<app>
		<name>astropulse_v6</name>
		<gpu_versions>
			<gpu_usage>1.0</gpu_usage>
			<cpu_usage>1.0</cpu_usage>
		</gpu_versions>
	</app>
</app_config>

Then add the Command Line setting to increase the GPU usage while just running one task at a time;
3) Find the ap_cmdline_win_x86_SSE2_OpenCL_ATI.txt file in your setiathome.berkeley.edu folder and paste the following line in the file;
-unroll 10 -ffa_block 4096 -ffa_block_fetch 2048 -sbs 256

See how that works for now.

Thanks Joe,

I can see where you are coming from then in this. Always good to have extra information.

Zalster

Edit...

More I think about it, I understand why for the repetitive.. Still not happy with the singles, but that's nothing new and I've learned with live with that. As long as it's only toes or fingers and not something more important, lol....Heart, liver, lungs...lets keep it clean folks.

Thanks Joe from the beginner's view if I could paraphrase what you have said is: We are not throwing out the baby with the bath water, only a few fingers and toes. :-)

I can't get any simpler than that!

Thanks TBar,
I just did that. Only one question thereto: If I have a 4 core 8 thread system, does that mean that I have to let one thread held as idle for each gpu that I have? In my 2 gpu setup that means I have to put 75% in "use at most" computer preferences. If that is the case it seems as though I would be putting quite a bit of power in an idle state. Right?

For now you can just alter the app_config file to run one at a time with 1 CPU core reserved. Hal's example will work for that;

<app_config>
	<app>
		<name>astropulse_v6</name>
		<gpu_versions>
			<gpu_usage>1.0</gpu_usage>
			<cpu_usage>1.0</cpu_usage>
		</gpu_versions>
	</app>
</app_config>

Then add the Command Line setting to increase the GPU usage while just running one task at a time;
3) Find the ap_cmdline_win_x86_SSE2_OpenCL_ATI.txt file in your setiathome.berkeley.edu folder and paste the following line in the file;
-unroll 10 -ffa_block 4096 -ffa_block_fetch 2048 -sbs 256

See how that works for now.

With the app_config.xml setting it will automatically reserve the CPU cores/threads for the GPU. So you do not have to adjust your computing preferences. If the GPUs run out of work a CPU core will revert to running a CPU tasks if there are more to do.
If you were to have
<gpu_usage>1.0</gpu_usage>
<cpu_usage>2.0</cpu_usage>
Then 4 CPU cores/threads would be reserved while 2 GPU tasks were running.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

Thanks Hal
Whoops I mean Hal9000, pardone. :-)

HAL9000,

Yes, thank you, I will put my 6570 over to machine2 with my 4650 by using the riser idea that Zalster gave me. Over at 'Help - GPUApps', I asked for ideas on what my upgrade path would be and the response was the r7 265 so that is what I bought. If the price was about the same I would have gone with the r7 270 had I known about it. Also,I will try harder to go in the right direction from now on. :-) Yours truly,
merle van osdol

Interesting choice. I would have gone with the R9 270 myself. As it is the same power usage & about 25% faster.

If you add a card like that I would remove the 6570. Having a card that much slower than two faster ones may throw off the estimates. Which will could cause your system to start throwing out errors instead of getting any work done.

The general idea is to get as much done as possible, but you seem hell bent on going the other way. :P

HAL9000,

Yes, thank you, I will put my 6570 over to machine2 with my 4650 by using the riser idea that Zalster gave me. Over at 'Help - GPUApps', I asked for ideas on what my upgrade path would be and the response was the r7 265 so that is what I bought. If the price was about the same I would have gone with the r7 270 had I known about it. Also,I will try harder to go in the right direction from now on. :-) Yours truly,
merle van osdol

Interesting choice. I would have gone with the R9 270 myself. As it is the same power usage & about 25% faster.

If you add a card like that I would remove the 6570. Having a card that much slower than two faster ones may throw off the estimates. Which will could cause your system to start throwing out errors instead of getting any work done.

The general idea is to get as much done as possible, but you seem hell bent on going the other way. :P

I really meant that in the sense that before you had worked out the issues with the current setup you were looking to add a 3rd GPU to cause even more issues for yourself.
The R9 270 probably does cost more so the R7 265 might be a better card for the money.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

Speaking of Blanked APs, this last set of APs that came out are heavily blanked. Normally unblanked APs take about 55 minutes to run.. Aside from the occasional AP, a majority that I've crunched thru this past week have taken about 3 hours. Maybe that is why it was such a short run this time with the "tapes"? They suspected that there was a large amount that would be heavily blanked and didn't want to overload us with them? Just a thought.


Zalster