Scramble (May 27 2009)

Had a few more bandwidth woes early in the morning. Turns out this was due to the replica recovery yesterday - a lot of long queries were still being aimed at the master. I turned the replica on, which immediately helped (though it is about 10-15 hours behind and slowly catching up so some stats may seem a little screwy).

Before we figured that out Jeff and I were a bit stumped as we thought this had to do with Astropulse work availability. In the process of looking for clues we discovered that for a long time Astropulse had an extra defunct project sitting in our applications table. This meant the feeder was saving a third of its slots for a project that will never have any work. I fixed that. I don't think that was causing any major problems lately, but it sure wouldn't help them, either.

This morning I dusted off some code - a program that would fix our doubly-precessed signals. I was hoping some changes Eric had since made to the (incredibly arcane) database code would have fixed some long standing problems, but they didn't. This isn't Eric's fault - it's some garbage in the esql libraries that won't let me do updates to rows with user-defined types. This normally isn't a problem as we can insert signals just fine. Updating them, however, is the problem, at least using esql. So I'll shelve this project once again - in the meantime we have a patch of signals that we cannot use to find candidates as their coordinates are slightly wrong.

Oh yeah - people were asking: I'm not sure when video of our anniversary talks will become available. The students involved in the filming/editing are also working on SERENDIP V, and they're in a mad scramble to get that ready for deployment down at Arecibo next week.

- 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

Matt,

Are you absolutely sure that all the old Astropulse workunits have got their canonical results and been purged from the database? We've been watching the issue rate decay slowly over the months since _v5 launched, but nodbody's found a way of knowing that the database is 'clean' of these oldies. Wouldn't it be better to do an actual check of the database, rather than just 'discovering' that you aren't - obviously - deliberately creating any new ones?

Also, there's been yet another Astropulse - _v5b? _v6? - simmering on the back-burner in Beta for absolutely ages. Eventually, someone will get round to declaring it cooked: we have been promised that, as with _v5, it will be launched as a new application.

When that time comes, Joe Segur suggests that it will be much better to skew the feeder slots to match the workunit demand. Instead of 33:33:33. he suggests something like 95:4:1 for multibeam / active AP / AP resend tail. That way, you wouldn't have AP galloping through the fresh tapes as soon as they're loaded, and a huge storage backlog of tapes split by AP but waiting for MB processing.

Ok, next question, does any of this have anything to do with us not being able to upload completed tasks?