Fallen Leaf (Feb 12 2009)
Fallen Leaf (Feb 12 2009) |
|
| log in |
Message boards : Technical News : Fallen Leaf (Feb 12 2009)
Previous · 1 · 2
| Author | Message |
|---|---|
|
Good questioning but sorry, I don't see what direction you're aiming for... a) "right" shape is questionable by itself. New AP 5.03 tasks (for example) give very high overlowed exit ratio still (sampling too small still though, maybe just weird deviation). Noise "shape" here is likely intended to mean the spectral plot shape. The idea is to have the inserted noise look like background noise for that WU. I imagine that the transition from WU signal to inserted noise and then from inserted noise back to WU signal is going to be a very subtle trick to get it to gently blend without the FFTs 'seeing' the joins. My own line of attack would be to use noise blanking techniques to cancel out just the radar interference itself. I don't know if that would be less or more difficult than the 'blank noise' insertion. b) noise can be inserted by server or can be inserted by client (even less work for server maybe) if client will know what areas it should blank (as doing now in AP client blanking). Anything more complicated for the clients could well become a nightmare for the optimisers! c) sure we can't just skip some time areas w/o bad consequencies, but some of processing can be skipped. For example, doing single pulse search in "blanked" data meaningless from scientific point of view and wasteful from performance point of view. Maybe, another kinds of searching can be modified too for alternative accounting of damaged areas. Perhaps just accept the data "as-is" and have the clients ignore all the pulses found in the radar contaminated bits... Yes, this requires some modifications ... so task size increase souldn't be too dramatical. I agree to keep all relevant data possible in with the WU for a "just in case" review further down the line. That could save a lot of reprocessing for any hiccups anywhere... Regardless, trying to keep the data clean is a very difficult problem. Far far better would be for the radar not to be there in the first place. Keep searchin', Martin ____________ Mandriva Linux A user friendly OS! See new freedom Mageia2 The Future is what We make IT (GPLv3) | |
ID: 866582 ·  | |
|
Raistmer Volunteer developer Volunteer tester  Send message Joined: 16 Jun 01 Posts: 2626 Credit: 26,613,949 RAC: 35,381  | |
Anything more complicated for the clients could well become a nightmare for the optimisers! It's optimizers problems, right? ;)
Clients should know what areas are contaminated for that. It's the aim of this proposal - let client know what is real and what is not. How this info will be used and how hard it will be to use this info - it's just completely another question. And I don't propose to change current processing algorithm (it's difficult) I propose to provide possibility of such change (it's much more easy). | |
| ID: 866826 · | |
|
Hey Matt Lebofsky, | |
| ID: 866835 · | |
 Matt LebofskyVolunteer moderator Project administrator Project developer Project scientist  Send message Joined: 1 Mar 99 Posts: 1376 Credit: 74,079 RAC: 0  | |
I want try to get OEM or ThirdManufacture RAM if not to expensiv. We'll need to open the machine to find out - it's already a mixture of different sizes. Then we'll let you know if we need anything - thanks for the offer! - Matt ____________ -- BOINC/SETI@home network/web/science/development person -- "Any idiot can have a good idea. What is hard is to do it." - Jeanne-Claude | |
| ID: 866909 · | |
Message boards : Technical News : Fallen Leaf (Feb 12 2009)
| Copyright © 2013 University of California |
