Matt/Eric/Jeff: The raw tape 18DC09AA has been in limbo for weeks and weeks, never going beyond 12, and keeps several splitters sequestered from other data files. It needs attention to be fixed or discarded.

Just do a quick search on the forums to see how often it has been mentioned.

Thanks

bump

Yes please do something about it as it maybe the root to 1 or 2 of the problems around here of late.

Sorry that I've mentioned/harped on this file several times over the last few weeks now but it really does need to be taken out of the loop and examined more closely.

Cheers

---

As it happens, I've been getting hundreds of tasks from 18dc09aa - at SETI Beta. They're all shorties, which is invaluable for testing David's new quota management system. I'm able to get through a full daily quota in about five hours from a standing start, on the GTX 470.

I wonder if some of the hasty re-building after the web-hack three months ago allowed the Beta splitters to appear on the main project status page - there's no similar splitter feedback at Beta.

As it happens also, the last new WU split here is also from 18dc09aa. But it's from the 8th channel, not one of the last three. And that last WU was split about 1.5 hours ago, so I think the troops are on the case. The "Data Distribution State" on the server status page hasn't updated recently...

                                                                Joe

Well that file has now hit (14) again and the splitters are going down with no other work so we should see soon if this file gets reset again.

---

As it happens also, the last new WU split here is also from 18dc09aa. But it's from the 8th channel, not one of the last three. And that last WU was split about 1.5 hours ago, so I think the troops are on the case. The "Data Distribution State" on the server status page hasn't updated recently...

                                                                Joe

I mentioned it yesterday on boinc_alpha as a possible, but unlikely, contributor to a bug I was reporting - that may have gained it some extra notoriety.

bump

Well that file has now hit (14) again and the splitters are going down with no other work so we should see soon if this file gets reset again.

Well, that puts paid to both our theories.

Both the Main and Beta projects are out of work, and yet the server status page still shows those same three splitters working on 18dc09aa........

Time for the big boot in the direction of the trash can, I think.

I saw somewhere that 18DC09AA was created and is being used for tasks created as part of Matt Lebofsky's solution for removing problem RFI from tapes being split.

It would be good to hear confirmation that this is so (or not, as the case may be) as this thread has been running for months now and the general consensus of opinion at present tends to the belief that it is a repeating bug.

Keith

Yes, that previous thread was pointing out that in general we are lately repeat crunching. The 18DC09AA tape was simply verifyable since it exists historically in our logs at very diverse date points --- plus it's growing immortality seems to be vexing some folks, thus it's gotten a lot of unrelated mentions.

The other suspicion on repeats of data is based on the naming convention .. namely, we're reliant on ALFA scan time, and a single 50 gig tape historically represented about 4 hours of recorded time ... and you were very very lucky to get 10 hours of ALFA observations to piggy back on in any given day ... thus AA, AB, AC ... well now we have sequencing of AD, AE, AF, AG, AH, AI, etc ... on a given specified date. So either the frequency range was significantly increased with no mention, or the tapes are being repeated manually with no mention, or the normal time continuum no longer applies to Arecibo with no mention, or the naming convention is just plain out the window with no mention.

Back then I was hoping to check the source code to see what changed in the queueing code, but source browsing has been offline for ages (JS pointed me at an alternate, but it appeared relatively old -- apologies if I misunderstood).

Cheers, Aces

Yes, that previous thread was pointing out that in general we are lately repeat crunching. The 18DC09AA tape was simply verifyable since it exists historically in our logs at very diverse date points --- plus it's growing immortality seems to be vexing some folks, thus it's gotten a lot of unrelated mentions.

The other suspicion on repeats of data is based on the naming convention .. namely, we're reliant on ALFA scan time, and a single 50 gig tape historically represented about 4 hours of recorded time ... and you were very very lucky to get 10 hours of ALFA observations to piggy back on in any given day ... thus AA, AB, AC ... well now we have sequencing of AD, AE, AF, AG, AH, AI, etc ... on a given specified date. So either the frequency range was significantly increased with no mention, or the tapes are being repeated manually with no mention, or the normal time continuum no longer applies to Arecibo with no mention, or the naming convention is just plain out the window with no mention.

Back then I was hoping to check the source code to see what changed in the queueing code, but source browsing has been offline for ages (JS pointed me at an alternate, but it appeared relatively old -- apologies if I misunderstood).

Cheers, Aces

The current 50.2 GB files with 14 data channels plus radar blanking represent about 1.5 hours of ALFA observations. A 750 GB drive could produce 15 files, a 1 TB drive even more, and the drives are not always changed out daily. But I think they're using the sequencing to distinguish which kind of radar removal was applied, so there are likely to be twice as many files.

The source code browsing feature is working now for me, requires accepting the self-signed certificate for setisvn.ssl.berkeley.edu though. I don't browse that way often, a full checkout of the code so I can deal with it locally is less frustrating with my dial-up connection.

                                                              Joe

Hooray !!! 18DC09AA seems to have been removed !!! Thanks, guys

The source code browsing feature is working now for me, requires accepting the self-signed certificate for setisvn.ssl.berkeley.edu though.

Thx Joe, but I don't see how anyone can get around a 404 ;-) What sanctioned uptodate link is there besides http://boinc.berkeley.edu/cgi-bin/cvsweb.cgi/ ??

The source code browsing feature is working now for me, requires accepting the self-signed certificate for setisvn.ssl.berkeley.edu though.

Thx Joe, but I don't see how anyone can get around a 404 ;-) What sanctioned uptodate link is there besides http://boinc.berkeley.edu/cgi-bin/cvsweb.cgi/ ??

Do you check threads you started sometimes? For months already sources in SVN repository I pointed to you about week ago already.

Do you check threads you started sometimes? For months already sources in SVN repository I pointed to you about week ago already.

Yes I did joe, and the sources looked stale, but I'll look again, thx as always. Fact remains the pirmary site links to sources are dead, kaput, etc.

Its great to finally see the end of that file. :)

---

The source code browsing feature is working now for me, requires accepting the self-signed certificate for setisvn.ssl.berkeley.edu though.

Thx Joe, but I don't see how anyone can get around a 404 ;-) What sanctioned uptodate link is there besides http://boinc.berkeley.edu/cgi-bin/cvsweb.cgi/ ??

From the Porting and optimizing SETI@home page, the link to browse the repository is https://setisvn.ssl.berkeley.edu/trac/browser. That's the approach which worked for me.

                                                               Joe

Its great to finally see the end of that file. :)

I just wonder if 24dc09aa will replace it !!!!!
I feel sure I saw somewhere that the old "dummy task" was being used somehow for the blanking of RFI, but am not at all sure of that.
it certainly looks strange, consisting entirely of errors.

Keith