It has, ofcoarse, pro's and con's, the pro is, that twice the work can be done in the same time and takes off the load off the UP- and DOWN-Load servers, validators, file deleters. The spitters and database-storage will get more work.
The 'con's ' , have been expressed in the previous posts.
But maybe it's the only way to get all the work done, with the current hardware situation!?
Is it safe enough to rely on the BOINC manager and regular 'checks on hosts', to eliminate fault's (and possible fraud?)
Is the need for speed, that great or really needed?
I do find it a difficult question to answer, but it makes a lot off checking and validating, redundant.

---

I'd be happier with the redundancy.

My boxes have been behaving themselves for ages, but Murphy's Law means that if one of them loses the plot, it will be when I'm away for a week or two, and I'd hate corrupt results to get into the database just 'cause I'm on holiday and my crunchers aren't!

Alan Woodford

---

The Greying Lensman

Do it! My CPU is trustworthy. It has references... it has well know referen... it's references are Morgan Fairchild... it's wife... who it's slept with.

YEAH! That's the ticket!

---

No need for speed in this case.........
The signals we are looking for, if they are present, are eons old.

Whether we crunch them today......or tommorrow......or next week.....or next year....................just doesn't matter that much.

IF the 'signal' is ever found.......and we are really playing all our chips on the bet that 'they' would even broadcast a signal thet we would receive.......in a radio spectrum that we would monitor......man, that's a big gamble......

In the time is has taken for such signals to arrive here, if any.......it is likely that such civilization will have long past.

But I still revel in the search....because.....

IF we ever do find evidence of such a signal.......it would mean that we are, or were, not alone. And that would just rock humankind's world.........

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

No need for speed in this case.........

HUH?

Is this coming from the fastest kittiefied quad in the world?

Unbelievable

The 'ALIENS' may have time, but have we or SETI, that much time?
That's what we are talking about, I get the impression, that the whole SERVER CABINETT, needs replacement for faster 'splitting, sending out, receiving and validatin, compairing and storing it in the master-science DATABASE.
Not to mention the way the information from Areicibo has to get to Berkeley (SETI), (sending/receiving HDD's full off {Precious}DATA) is not the easyest way. But a 'fibre' between those 2, isn't easy/cheap, as well.{Using a transmitter, a kind off WLAN???}
Priorities have to be set, but that, again raises more questions about funding, the project. But as time passes, 'we' have to move with it, or we'll likely to fall behind in a way, where no obvious and/or easy solution, can be accomplished.
Just a few thoughts from a foreign cruncher ;)

---

The 'ALIENS' may have time, but have we or SETI, that much time?

I can't answer that, but if we crunch with out a wingman there might be times where there are no work brcause the data gets crunched to fast. just my thoughts. I'm sure Matt and the team will ake the right choice n the coming weeks.
Speedy

---

IF the 'signal' is ever found.......and we are really playing all our chips on the bet that 'they' would even broadcast a signal thet we would receive.......in a radio spectrum that we would monitor......man, that's a big gamble.......

I am ALL IN

---

In a way, it all IS a big gamble, since we don't know their current state off technical capabilities and their 'time-frame'.
Nor do we know, where a signal will be comming from and what kind off modulation, frequency*, source and amount off power, they are likely to use.
We don't even know, for sure, if they have 'visited us before' and 'if' when 'this' has happened.
Maybe, after a visit, 'they' decided NOT to make contact, seeing our current state, that is, conflicts throughout the whole world, 2/3 off the worlds population having no steady food and water supply and so on.
But, this is, ofcoarse a lot off speculation and NOT facts, wich we so desperatly need.

*We assume, they'll use the 'hydrogen' (resonance?) freq. band, but they could also be using forms off laser emission or something, we haven't invented yet?
Now, I'll really stop, wandering, ;)
Again, just more thoughts off a enthousiastic cruncher.
For now, I'll keep on crunching, ;^) and hope to find a sign of them.

---

W/O wingman results will be untrusted much more than with it.
We can go with amazing speed but why we will do that if our results will be untrusted???? We need RELIABLE results.

W/O wingman results will be untrusted much more than with it.
We can go with amazing speed but why we will do that if our results will be untrusted???? We need RELIABLE results.

You are absolutely RIGHT about, getting reliable results, part off this checking happens in(side) BOINC, when the WU is finished. It validates or not.
Has the 'checking by processing the same WU, by yet another cruncher, not only to do with the validating process and the amount off credits, earned/given?

When I look at 2 or 3 validated WU's, the number off found spikes, pulses, triplets and gaussians, is gives(almost* everytime**) the same numbers, while the claimed credit differs almost anytime.
*I have never seen validated results with a different number off found signals.
(**Canonical Result)
I'am absolutely for error-free results, that's normal, because better NO result at all, then a worthless one.
I appreciate your comment and you are more/longer involved in this project, then myself, but 'this can speed-up processing', almost 100%, wich makes a huge difference, but never at the cost off invalid results, though.

---

Matt,

While I love the idea that you are thinking outside the box, I must agree with the others that we keep a wingman.
To quote Reagan "Trust but Verify".

Later

I look at this question (zero redundancy) a little different. First, there are really two questions here: that of credit granting and that of finding ET. In the first case, redundancy assures a check against cheats (unless most of us cheat rendering redundancy moot). Without redundancy, one would have to invent a different strategy for validating credits, which seems doable but would take some new procedures be invented, as suggested below.

In the second case, it seems reasonable to have zero redundancy, especially if the sky scans themselves are to some level overlapping (or otherwise redundant). That is because the overwelming liklihood of any wu detecting ET is near to zero, for many reasons. So, assuming we don't have enough compute power to 'keep up', I would think a good compromise would be only to issue redundant wu's when a 'signal' has been detected and needs to be verified. Assuming the clients make very few mistakes, we would miss a very few false negatives in this fashion, of course, and would have to rely on subsequent sky scans to detect them. But we would find the positives (true or false) much more quickly.

The affect on the other missions of the AstroPulse is not as clear to me. So they may be the reason to keep redundancy. But, afterall, "main-frame" supercomputers don't have redundancy at this high level for any one calculation.

Another thought would be to incorporate some level of verification within the science client itself, abstractly a sort of sophisticated checksum. This approach would extend the average compute times, but reduce the server load. For example, the simplest example would be to compute each wu's twice. (Yuk) Or, a random flag could be set to have the client re-compute every once in a while. Etc. If someone knowledgeable thought about it, there may be some better (smarter) approaches.

But, afterall, "main-frame" supercomputers don't have redundancy at this high level for any one calculation.

The difference is that the mainframe owner (and there is one owner) can do periodic maintenance, that the vendor will guarantee specifications and performance, error rates, etc.

With a BOINC project, the results are sent into the wild, and the project knows nothing about that machine: performance, accuracy, stability, and honesty are all unknown.

I don't think that many people are out to cheat, it seems far more likely to find broken or unreliable systems.

---

I don't think that many people are out to cheat, it seems far more likely to find broken or unreliable systems.

What makes you say that?

I don't think that many people are out to cheat, it seems far more likely to find broken or unreliable systems.

What makes you say that?

Oh, no reason in particular. (ducking)

---

Been doing some thinking and that is very dangerous...

If you go without a wing man what is the damage that is possible?

You have three kinds of people who will cheat.
a) The credit hog. He'll return a nonsense result where there might have been a signal or noise.
b) The attention hog. He'll return a yes result all the time.
c) The head in sand. He'll return a no result all the time.

Then there is the failed computer.
a) fails to detect
b) detects on noise

I'm ignoring data transmission errors because I assume the project can detect that. I'm also ignoring the fails to return result as that is detected.

I'm guessing a credit hog could seriously damage the integrity of the science database. Someone like this may have a large farm of machines and return thousands of bogus results per day. Once detected all those results will need to be purged. The question becomes can you re-issue the work units or has this credit hog just turned the receiver off?

The attention hog gets caught when you try and do a verification of signal with telescope time, if not sooner. If he doesn't set up a farm and send thousands of results then the damage is minimal, but costs actual $$ for the telescope time spent looking at noise.

The head in sand is the worst. He may not ever be detected as his noise result is the expected result. He will cause us to miss our chance to find ET.

As for the failed computer, I suppose every so often the project could send a reference work unit to the machine to see if it returns the known result. Or it could send a live work unit out and issue it to a random wing man. In either case there is the problem of what to do with all the work units that machine has crunched since it last passed its test. Does someone have to remount dozens of "tapes" and have the splitters find parts in question to have them re-sent?

If our project were one where you could look at the result data to make sure it made sense before storing it, then not having a wing man would not have the potential to destroy the validity of the science database. But our project isn't like that.

While I'm sure well over 99.9% of our results validate, however is that because we must crunch the data? Without that check being known how many people would suddenly turn into credit hogs and return bogus results? Might make for a social science paper, but not an astronomical one.

Gary

---

Remedies...

Credit hog: At worst, he returns a false-negative. We should accept the inefficiency in order to get more work done.

• In sky areas that are oversampled, then the false-negative has a good chance of being reversed with time.
  
• In sky areas that are under-sampled, a different approach should be taken in which the astronomers could ask for confirmation by sending out redundant units for analysis; or, re-observe the area; or both.
  
• Excursions in credit can be caught with the occasional automatic check, and reversed accordingly.
  

Attention hog: This guy gets kicked out right away. Easy. Any positive result should be automatically validated by several more than two computers, and similarly positioned wu's should be likewise scrutinized. So a chronic attention hog will be noticed and excluded from participation. Easy.

Head in Sand: Again, his false-negatives will be ferreted out with time, as above. Plus, this hog is probably just oveclocking his Atari and will drop out in time.

The worst case would be if the client base were all hogs of some sort. Then the project is broken. Objectively, however, the fix is easy and one could resort to quorems larger than 1.

The simple argument for a quorem of 1 is that we can filter through the data 2x as fast and with a lot less cost and complexity at Berkeley. If 99.9% of the clients return valid results, then the likelihood of finding a true-positive rather than a false-negative is likewise very high. And remember that any postive will be checked and rechecked exhaustively.

The simple argument for a quorem of 1 is that we can filter through the data 2x as fast and with a lot less cost and complexity at Berkeley.

The cost and complexity is already paid for: the splitters already split two work units, and the validators already compare work units.

I don't think the change in human resources or hardware at Berkeley is a significant argument either way.

The "cost" is in the false negatives. Sure, there aren't going to be a lot of work units that had a signal and got missed, but there aren't many work units that have signals worth looking at originally.

We're a litmus test: we're trying to weed out all of the work units that aren't interesting, so that further analysis can be done on those that are.

---

Cost & complexity is reduced because wu's are stored for less time on the server and booking for one wu is less than for two (or more if multiple wu's are needed).

Recovery after filling up disks, sorting databases out, and so on take human resources. Seems pretty clear to me.

Yes, the cost is is false negatives. But the statistics prove that the cost is small and inconsequential given the return we get by parsing through the raw data faster. Perhaps you don't believe the statistical argument.

I would also add to what I said before that even if we miss ET1 will we miss ET2? or ET3? It is highly unlikely there is only one other civilization, if we believe there is one. So it is highly, highly unlikely our screen will have false negatives on every one. (That is not to say we shouldn't verify our reliability; I just think it is dumb to argue we need so much redundancy.)