I know that AP tasks are blanked. I want to be sure I understand blanking; MB tasks, I would assume, would also be blanked, correct?

I know that AP tasks are blanked. I want to be sure I understand blanking; MB tasks, I would assume, would also be blanked, correct?

Not so much. You may see some MB tasks that finish much shorter than other. Often < 60 seconds. In those look for
Spike count: 30
&
SETI@Home Informational message -9 result_overflow

---

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

Looking at it from the science side of the ledger, I guess because MB is narrowband therefore the interference signals would logically be much less of a problem to "clean up" than with the broadband signals.

Where is this "spike count" and the other found?

Looking at it from the science side of the ledger, I guess because MB is narrowband therefore the interference signals would logically be much less of a problem to "clean up" than with the broadband signals.

Where is this "spike count" and the other found?

In the <stderr_txt>. Here is an example.

---

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

Thanks.

I know that AP tasks are blanked. I want to be sure I understand blanking; MB tasks, I would assume, would also be blanked, correct?

For MB, there's no client side blanking. But for both MB and AP there's server side code which looks for the known patterns of the Puerto Rico radars in the combined data from multiple channels. Parts of the data which are affected get replaced by shaped pseudorandom data as they are loaded into the splitters.

For all of Classic and the first few years of seti_boinc, the data was coming from a different feed antenna and receiver which apparently wasn't affected noticeably by those radars so blanking was not developed. After shifting to the ALFA receiver system with multiple beams, some tape files were badly affected. At Arecibo there was already a special receiver setup to detect the pattern usually used by the strongest radar, so its output was connected into a 15th channel of the multibeam recorder and the splitter code was modified to blank data based on that signal. That was termed hardware blanking. Then Matt Lebofsky took on the task of developing software algorithms which could detect the radar patterns even for data recorded prior to having that 15th channel to control blanking. That effort eventually became more effective than the hardware blanking, so that "software blanking" is now used.

That radar pattern matching seems quite effective against the known radar RFI, but of course it is not effective against some other things which can cause similar problems. Murphy's Law still applies.

                                                                  Joe

Thanks Joe,
It's taking me time to understand why blanking would be for both on the server side but only for AP on the client side. I'll work on it.

Thanks Joe,
It's taking me time to understand why blanking would be for both on the server side but only for AP on the client side. I'll work on it.

What gets done on a shoestring budget is the bare essentials. Client side blanking in AP is because Josh Von Korff was developing the code for his Doctorate, and decided it was worthwhile. MB might possibly benefit from something similar, but the existing method of quitting when too many signals are found has served well enough until now.

                                                                   Joe

Ah, now I see.

Thanks for the help Joe.