Rainy Day Data (May 14 2009)

We are quite preoccupied with anniversary stuff so we've been doing the bare minimum amount of systems administration to get by until after the event. Still, it should be mentioned we continue to have SATA/driver issues on our data recorder at Arecibo, and haven't collected new data for about a month now. While we have a pile of data yet to crunch readily available on disk, I started pulling up unanalyzed data from our offsite archives.

Before doing so I went through the whole data inventory rigamarole this morning. We have 1787 raw multi-beam data files (mostly all 50GB in size) archived, of which 338 haven't been split at all. However, a portion of these files were recorded before 2008, i.e. before we had a hardware radar blanking signal embedded in the data. So until we get my software radar blanker working (a project postponed until post-anniversary) we can't chew on these files without dealing with major radio frequency interference. This isn't a major problem: 1225 of the 1787 archived data files are from 2008 or later, and of these 249 have yet to be split. So we got plenty of numbers to crunch until we get the data recorder working again.

- 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

We are quite preoccupied with anniversary stuff so we've been doing the bare minimum amount of systems administration to get by until after the event. Still, it should be mentioned we continue to have SATA/driver issues on our data recorder at Arecibo, and haven't collected new data for about a month now. While we have a pile of data yet to crunch readily available on disk, I started pulling up unanalyzed data from our offsite archives.

Before doing so I went through the whole data inventory rigamarole this morning. We have 1787 raw multi-beam data files (mostly all 50GB in size) archived, of which 338 haven't been split at all. However, a portion of these files were recorded before 2008, i.e. before we had a hardware radar blanking signal embedded in the data. So until we get my software radar blanker working (a project postponed until post-anniversary) we can't chew on these files without dealing with major radio frequency interference. This isn't a major problem: 1225 of the 1787 archived data files are from 2008 or later, and of these 249 have yet to be split. So we got plenty of numbers to crunch until we get the data recorder working again.

- Matt

We are quite preoccupied with anniversary stuff so we've been doing the bare minimum amount of systems administration to get by until after the event. Still, it should be mentioned we continue to have SATA/driver issues on our data recorder at Arecibo, and haven't collected new data for about a month now. While we have a pile of data yet to crunch readily available on disk, I started pulling up unanalyzed data from our offsite archives.

Before doing so I went through the whole data inventory rigamarole this morning. We have 1787 raw multi-beam data files (mostly all 50GB in size) archived, of which 338 haven't been split at all. However, a portion of these files were recorded before 2008, i.e. before we had a hardware radar blanking signal embedded in the data. So until we get my software radar blanker working (a project postponed until post-anniversary) we can't chew on these files without dealing with major radio frequency interference. This isn't a major problem: 1225 of the 1787 archived data files are from 2008 or later, and of these 249 have yet to be split. So we got plenty of numbers to crunch until we get the data recorder working again.

- Matt

Nice to hear about the MB data, but where does this leave you with AP data?

Hope you get the problems as Arecibo fixed soon. Wouldn't want ET to try and call when we aren't recording.

For the off chance it hasn't been seen yet, all the 'ap_splitter's are not running..

with the anniversary coming up and the press coverage that it will generat you might want to have a lot of units ready for new/returning or currant accounts. it would look bad it you ran out of work after all the time you all have put in for the anniversary events.

As of 17 May 2009 20:40:09 there is no ap data been split, mb data is been split at 19.3919. Iwill be sweet data wise until after the weekly outage. Id no new data is added until tomorrow or even until after the weekly outage it will be interesting to see how many results are waiting to be returned. Currently there are 430,111 results waiting to be returned.
____________

Live in NZ y not join Smile City?

As mentioned there are a lot of the dreaded VLAR workunits out at the moment, I had several all auto-killed with the optimized app as error -6. Had one with this which is something I have not seen before.

Error in ap_remove_radar.cpp: generate_envelope: num_ffts_performed < 100. Blanking too much RFI?

____________

Thats right, people that get VLAR workunits can help by letting these run to free space up for good work units. Thanks for letting these tasks run 1st
____________

Live in NZ y not join Smile City?

I do not think that is a fair point at all, if they slow your PC/GPU to a crawl in some cases then why run them?, to free up space for good workunits (define a good work unit, it is the data on the tape that determines that)

Personally I could let them run easily, as could anyone who received them, the point being though is they are annoying to some crunchers and not everyone likes them. It is personal choice to run optimized apps with a VLAR autokill. I do use my PC for other things other than SETI, so why should I compensate for possibly finding "a signal" in a work unit against actually being able to use the PC.

VLAR's affect my computer and I am sure several other crunchers who choose to kill them. They get crunched eventually either by someone with a machine who doesn't get effected or as much as I hate to say this, by a new user joining who has no idea what is going on when receiving a VLAR.

The project is doing amazing work on a budget that is probably laughed at in the scientific community (no offence meant there), and yes it has hardships but as MATT mentioned, they are reluctant to change anything major until after the anniversary. People are willing to spend their money on donating to the project, but it is not enough to cover every possible problem that arises.

Who knows (apart from a select few) what may happen after the anniversary, things will am sure will have to change in some way or another as it will generate more users depending on the overall coverage worldwide and within the scientific community.

I do not mean this post to be an attack on anyone, anything in any way. It is my opinion and not meant to open up discussion on what is the right or wrong thing to do, I leave that to the project admins and face the consequences of whatever they decide to do.
____________

... Had one with this which is something I have not seen before.

Error in ap_remove_radar.cpp: generate_envelope: num_ffts_performed < 100. Blanking too much RFI?

... Had one with this which is something I have not seen before.

Error in ap_remove_radar.cpp: generate_envelope: num_ffts_performed < 100. Blanking too much RFI?

These have been discussed and analysed in Number Crunching. There was a stuck bit in the B3_P1 recording channel for about a month: the staff should be aware (at least, they will be if they read email from Josef W. Segur!)
...