Heads Up: Quorum Change

Hello, generous donators of CPU time.

As we ramp down the current data analysis to make way for the hot, fresh multibeam data, we are going to change the quorums for result validation very soon. Perhaps tomorrow. Currently we generate four results per workunit, though three are enough for validation. We're changing this to three and two.

This means less redundancy, which has the wonderful side effect of consuming less of the world's power to do our data analysis. However, be warned that this may cause us to run out of work to process from time to time over the coming weeks, especially if we lower the quorum levels even more (two and two).

There's concern that "no work available" will cause us to lose valuable participants. Maybe it won't. In any case, hopefully we can get the multibeam data going before the well drains completely.

- 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

Hello, generous donators of CPU time. - Matt

Hi Matt ... thanks very much for the Good news!
_my Computer_id_5302_
_my Computer_id_5303_
_my Computer_id_5304_
_my Computer_id_5306_

Thanks Matt,
I think we better think carefully about the possibility of running short of work as the multibeam data on my C2D and Pent M reduce crunch time per task by about 70% on average. If this is true across all types of CPU/OS platforms then reducing replication to 3 will mean the number of tasks completed will approximately double.

And as since enhanced came on line most new cpu's are dual cores I hope the new servers can cope better with the database, when more than million/day tasks is once more back upon us.

Andy

Reducing quorum means less redundancy, which in turn means we need to create more work to keep up with "demand." In theory, we still have a bunch of "standard" SETI@home data to work with, so we shouldn't run out... but they are on DLT IV tapes which are slow to read, and we don't have a carousel or robot to feed the drive over nights or weekends. Currently I can throw one or two tapes in a day (four days a week) and that's just enough. Reducing quorum to 3 will increase splitter demand by 25%. And we may soon reduce it to 2, meaning splitter demand will increase by 50%. We can't feed our (only) DLT drive fast enough. Another DLT drive won't help - our network nor the file server can't handle the bandwidth. Plus we're very close to being finished with this data.

The tapes hold 35GB of data. The new multibeam data, however, are on 500GB/750GB hard drives. And we have two drive bays at a time available for reading. So we can keep a lot of data online without human intervention and feed it to the splitters over long weekends, etc. So running out of work is less of a worry, even with reduced redundancy.

However! If we ever "catch up" and we have a high demand for work to analyze, we will most certainly run out of work to send. This is obvious, but has never been the case, so our user base might be annoyed by this even though this is a happy problem. We'll cross that bridge, etc.

- 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

I forget the exact numbers, but if the redundancy level was 1, the reliability of the data was over 99% (i.e. less than 1% of the data was corrupt or bogus). Each level of redundancy above that is an improvement, but with diminishing returns.

The current data being analyzed by SETI@home has already been analyzed before, but with older versions of the client that did far less analysis (so workunits wouldn't take weeks to finish). There's a scientific reason to do so, but we're chomping on the bit to get to the new data because it's "deeper" in both frequency space and in sensitivity. Plus RFI will be easier to reject because of the multiple beams, etc. So reducing redundancy will help us push through the remaining old data.

One drawback of less redundancy is more "jagged" credit for workunits done (since they won't be averaged over the claimed credit of many users). Over the long term this will average out, but users who pay close attention will get annoyed by a few data points that make it seem they're being "short changed." Some PR will be necessary to smooth that over.

- 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

Thanks, Matt; this is enlightening. You have 1 tape drive that feeds the splitters. If the downstream demand increases due to reduced redundancy then someone needs to feed the drive at an increasing rate, which will lead to gaps during which the drive is dormant. You also have 'a bunch' of tapes left to analyze. So reduced redundancy will increase their processing rate, but potentially expose the project to gaps in WU availability.

Thanks, Matt; this is enlightening. You have 1 tape drive that feeds the splitters...

But why is the redundancy criterion being modified? The premise since Classic is that Seti needed a high level of redundancy to be believed. (I seem to remember questioning this premise a couple of years ago and getting blasted and later ignored by the community.) What model tells us that we can live with 3 or 2 in a quorem? The risk to the project is false positives as well as missing positives. (I am not aware of what kind of probability analyses have been performed on this topic.)

A secondary question is how long would it take with the current redundancy criterion to finish processing the 'backlog' of data tapes, assuming the current computing capacity as provided by the volunteers? That is, what is the aggregate number of WU's on the tapes, how many have been processed, how many can 'we' process per day? I realize that the tapes are being re-analyzed with more stringent criteria, leading to either more WU's or more compute time, or both.

Finally, is it possible that the new (multibeam) data is such an improvement in S/N (or similar criteria) that we risk wasting resources looking at the old tape data? Is this the driving factor for any change? ("hurry up and get to the new data") That makes sense, but it does seem risky to modify the redundancy criteria, unless we have been wrong all along by requiring a quorem of 4. In this case, I suggest just making a clean switch over as soon as possible, rather than having a bunch of 'half' analyzed datasets to worry about.

PhonAcq

You touched a Nerve! The Seti Staff and Many Volunteers have spent great amounts of Time, Effort and Money to move Seti to the Hope of Survival!

This has been the best conversation from the Seti Staff and identifiable progress in years...

Somewhere you missed that MultiBeam provides more data than 10X the users that are currently crunching... This does not mention that the change to the number of machines (Quorum) has been in testing (Seti Beta) for months... So now it getting ready for one of the next steps in Seti Evolution!

So, You are Welcome to donate the First of the New Servers that will start Near Time Persistency checking that will produce the scientific results from the stored Results... Or required reloading of old tapes for verification... You obviously did not read one of Matts posts that the now have enough data to finally start comparing the results, to see if there is something actually there...

Yes, it has been a very long Journey! I am a Supporter of the that Journey! I know that SETI Volunteers recently found between Seven and Eight+ thousand dollars worth of hardware to solve the Seti Server issues with the current Seti hardware... That work is still progressing...

* Where were you then?

* Why are you creating Hate and Discontent now?

* Or Again!

Yes I know that Matt answered parts of your questions... I still do not understand why you chose this point to drag up old cr@p! Obviously, you may have some preceived axe to grind, but your Credits show that you are happy with Seti (Status Quo) and have not left inspite some of your past complaints!

Regards

Pappa

This is a good opportunity for me to get on my "change control soapbox". Would someone give a good (technical, quantitative) reason for the change? Would someone give a good (technical, quantitative) analysis of the risk involved? It just seems like good project management to go to the effort to engineer the change (and good PR to publish the results).

...
I guess the question is for what is the probability (possibility) of getting two similarly incorrect results to fool the quorum checking?

Could two similar systems similarly overclocked or similarly overheated return results in the same incorrect way?

This has been the best conversation from the Seti Staff and identifiable progress in years...

Somewhere you missed that MultiBeam provides more data than 10X the users that are currently crunching... This does not mention that the change to the number of machines (Quorum) has been in testing (Seti Beta) for months... So now it getting ready for one of the next steps in Seti Evolution!...

This is a good opportunity for me to get on my "change control soapbox". Would someone give a good (technical, quantitative) reason for the change? ... (technical, quantitative) analysis of the risk involved?...

I forget the exact numbers, but if the redundancy level was 1, the reliability of the data was over 99% (i.e. less than 1% of the data was corrupt or bogus). Each level of redundancy above that is an improvement, but with diminishing returns.

The current data being analyzed by SETI@home has already been analyzed before, but with older versions of the client that did far less analysis (so workunits wouldn't take weeks to finish). There's a scientific reason to do so,

but we're chomping on the bit to get to the new data because it's "deeper" in both frequency space and in sensitivity. Plus RFI will be easier to reject because of the multiple beams, etc. So reducing redundancy will help us push through the remaining old data.

One drawback of less redundancy is more "jagged" credit for workunits done (since they won't be averaged over the claimed credit of many users). Over the long term this will average out, but users who pay close attention will get annoyed by a few data points that make it seem they're being "short changed." Some PR will be necessary to smooth that over.

- Matt

I see that the change is already in process. I've gotten several WUs that are the 3/2 format.

Yippee!!!

This following very important point (to some) is harking back to old discussions about having 'golden calibrations' so that credits can be more accurately awarded...

One drawback of less redundancy is more "jagged" credit for workunits done (since they won't be averaged over the claimed credit of many users). Over the long term this will average out, but users who pay close attention will get annoyed by a few data points that make it seem they're being "short changed." Some PR will be necessary to smooth that over.

- Matt

Happy crunchin',
Martin