Workunit (result?) 02ja05aa.18682.26401.436076.232, my Result ID 49209841, has 4 returned results. This would normally be more than sufficient to be granted credits. BUT it was retransmitted last night, 9/4/2005, at 23:14:37UTC, why?

Can any one explain please?

Andy

---

> Workunit (result?) 02ja05aa.18682.26401.436076.232, my Result ID 49209841, has
> 4 returned results. This would normally be more than sufficient to be granted
> credits. BUT it was retransmitted last night, 9/4/2005, at 23:14:37UTC, why?
>
> Can any one explain please?
>
> Andy
>

I've had a few of these lately as well. If you look at the bottom of the result page for this work unit, you'll see that it is listed as "Checked, But No Concensus Yet". That's why it was sent out again:

http://setiweb.ssl.berkeley.edu/result.php?resultid=49209841

If a concensus is never reached, you will be granted zero credit for the work unit. I have several in progress right now that will probably go that way. Not sure why this is happening so much recently.

Happy Crunching :)

Dig

---

I'm not an authority on the subject, but I have a feeling that the WU batch that come from the 02ja* data may have become corrupted somehow. That would explain the reason why everyone seems to be getting weird minute-long, inconsistent results.

Since I don't know how the data is stored, I can't say for certain.

It'd be a real pity if ET's signal is in there... :-/

---

Thanks Digger& NA&5borok
Its all as clear as mud now :-). Clicking arround I also Noticed that a couple of us had processed it with V4.10, one has used Linux V4,02 and the later re-transmissions are back on V4.09.

Think its going to be a big fat zer0.

Andy

Sic friatur crustulum - Thus, the cookie crumbles

---

> Think its going to be a big fat zer0.
>
> Andy
>
> Sic friatur crustulum - Thus, the cookie crumbles
>
HI, I looked at this set of results. This looks normal, and you'll probably get credit. Seti always sends out the WU to 4 hosts, then for each one that fails (Prior to validation) will result in it getting sent to another host. Seti obviously doesn't see three that agree (within a range) on the outcome. It's waiting for the last one to come in.

tony

> HI, I looked at this set of results. This looks normal, and you'll probably
> get credit. Seti always sends out the WU to 4 hosts, then for each one that
> fails (Prior to validation) will result in it getting sent to another host.
> Seti obviously doesn't see three that agree (within a range) on the outcome.
> It's waiting for the last one to come in.
>
I dunno Tony... it's been sent out six times, four of which can't reach concensus, one resulted in errors, and the sixth guy who's crunching it now has more client errors on his machine than successful results. Might have to watch this one just for fun. LoL. (Yeah, i know, get a life... but i'm recuperating from some stuff right now so i have plenty of time on my hands.)

Happy Crunching :)

Dig

---

> > HI, I looked at this set of results. This looks normal, and you'll
> probably
> > get credit. Seti always sends out the WU to 4 hosts, then for each one
> that
> > fails (Prior to validation) will result in it getting sent to another
> host.
> > Seti obviously doesn't see three that agree (within a range) on the
> outcome.
> > It's waiting for the last one to come in.
> >
> I dunno Tony... it's been sent out six times, four of which can't reach
> concensus, one resulted in errors, and the sixth guy who's crunching it now
> has more client errors on his machine than successful results. Might have to
> watch this one just for fun. LoL. (Yeah, i know, get a life... but i'm
> recuperating from some stuff right now so i have plenty of time on my hands.)
>
> Happy Crunching :)
>
> Dig

Hi Dig, This was the main reason I origionally started this post,

If concensus cannot be reached on 4 returned results, then there can be several conclusions; 1, there is one agreeing pr and two others, 2, two agreeing pairs or 3. four results where non concur.

situation 1 is hopefully most likely,

sit 3 is unlikely and if this is the case it should have been re-transmitted to more participats.

If its Sit 2 it again should have been sent out more than once.

Me thinks that the organisations running these projects could do with a database of trusted participants to send to when there are four or more returns and concensus is not reached - but its probably too difficult to organise/ write code etc.

Andy
Sentio aliquos togatos contra me conspirare. - I think some people in togas are plotting against me.

I have been seti crunching since 18 May 1999, first as andrewdothaworthat btinternendotcom (forced unintentional change of ISP when I moved) and then with my son Nutter.
>

---

> If concensus cannot be reached on 4 returned results, then there can be
> several conclusions; 1, there is one agreeing pr and two others, 2, two
> agreeing pairs or 3. four results where non concur.
>
Morning, I have done a study of the returned result, I've placed them in Excel Spreadsheet to look at these kinds of issues. here's what I found out about the number of times a WU is issued to get a successful validate. The columns (labelled left to right) are Issue count, # of occurances, %of total, % finished after n issues.

4 105 61% 61%
5 23 13% 74%
6 16 9% 84%
7 18 10% 94%
8 8 5% 99%
9 1 1% 99.50%
10 1 1% 100%

So, 61% of my results are validated after 4 issues, 74% after 5 issues, 84% after 6 issues, etc, etc.

Paul Buck has also done a study and you can find it on his website here

---

>
> If concensus cannot be reached on 4 returned results, then there can be
> several conclusions; 1, there is one agreeing pr and two others, 2, two
> agreeing pairs or 3. four results where non concur.
>

#3.

> >
> > If concensus cannot be reached on 4 returned results, then there can be
> > several conclusions; 1, there is one agreeing pr and two others, 2, two
> > agreeing pairs or 3. four results where non concur.
> >
>
> #3.
>
>If its four results were non-concuring why is it the workunit has only been re-transmitted once, I thought that 3 concuring results were needed. This at best will only produce two!

Another Q? this unit is from a batch starting 02ja, I have seen posted that there has been problems with these and I had at least 10 from there, 02ja, when I signed up on 31 Mar which processed within 300 seconds, which normally signifies they are noisy - could this be a similar problem.

---

Wow, what is going on today?

Another new topic for the FAQ ...

It has been a LONG time since I have added this many topics in one day ...

---

> If its four results were non-concuring why is it the workunit has only
> been re-transmitted once, I thought that 3 concuring results were needed. This
> at best will only produce two!

Not saying anything about the seti-validator, an easy example-validator needs 3 results, and uses error-limit +-1.
Let's say you've got 4 results: 48, 50, 52, 54.
These is outside the error-limit, so not validated.
If you adds a 5th result at 49, result 48, 49 and 50 is now just inside the limit and therefore validated.
The same for 51, validating 50, 51 and 52.
And 53, validating 52, 53, 54.

>
> Another Q? this unit is from a batch starting 02ja, I have seen posted that
> there has been problems with these and I had at least 10 from there, 02ja,
> when I signed up on 31 Mar which processed within 300 seconds, which normally
> signifies they are noisy - could this be a similar problem.
>

Don't know of any problems, but this doesn't mean there isn't any.

> Not saying anything about the seti-validator, an easy example-validator needs
> 3 results, and uses error-limit +-1.
> Let's say you've got 4 results: 48, 50, 52, 54.
> These is outside the error-limit, so not validated.
> If you adds a 5th result at 49, result 48, 49 and 50 is now just inside the
> limit and therefore validated.
> The same for 51, validating 50, 51 and 52.
> And 53, validating 52, 53, 54.

I'm assuming you hope that the results in so far are close, but not close enough, and that the re-transmitted unit when returned will be in a gap. BUT what if it isn't, how long will this go on and is it an efficient system?

---

>
> I'm assuming you hope that the results in so far are close, but not close
> enough, and that the re-transmitted unit when returned will be in a gap. BUT
> what if it isn't, how long will this go on and is it an efficient system?
>

In seti, if you can't validate with 6 "success"-results, the wu error-out.

> Another Q? this unit is from a batch starting 02ja, I have seen posted that
> there has been problems with these and I had at least 10 from there, 02ja,
> when I signed up on 31 Mar which processed within 300 seconds, which normally
> signifies they are noisy - could this be a similar problem.
>

The noisy units don't bother me at all. At least you get credit for what little time your CPU spends on them, and we've all had a bunch of these lately. As far as the validation issues go, it's just luck of the draw. Your machine may be very stable and produce good results, but your partners in crunching may not be. Or it could be a problem with the WU itself i guess. I have a unit just like yours that seems unlikely to reach concensus. The eighth guy to get it now has over 140 WU's in his cache waiting to be crunched, so it's going to be a while till i find out!

http://setiweb.ssl.berkeley.edu/workunit.php?wuid=11280272

Care to make a wager? LoL.

Dig

---

I assume (again) that there are download errors or sumthing for a unit to be sent to eight participants, see Inglesides last post.

To be honest I'm not that worried about noisy units but I had quite a few from the O2ja, only one of these could be called normal.

The WU ID of the O2ja units I have processed that did unusual things is:
11806816
11808012
11845073
11845103
11845109
11845119
11845125
11845126
11845136 stopped at half way
11845138
11845140
11845144
11845145 stopped at half way
11845146 stopped at half way
11845148
11845154
11960979 stopped at half way

All units not anotated completed in less than 3 mins on a slow machine P3 866MHz
Plus the one I started this discussion about.
Andy
quaere verum

---

Seti@home looks at 2.5 MHz wide spectrum centered around 1420 MHz, but it's too large to look on the full spectrum so splits it into 256 pieces.

Most of your listed wu is recorded at the same time, only differing in which of the 256 pieces of the spectrum it is. Any interference will therefore most likely affect all of these wu.

> Not saying anything about the seti-validator, an easy example-validator needs
> 3 results, and uses error-limit +-1.
> Let's say you've got 4 results: 48, 50, 52, 54.
> These is outside the error-limit, so not validated.

Ingleside,

how about this example:

let's say we've got the following 4 results: 48, 49, 51, 52. They are groupped in pairs and we don't have a consensus of 3. So the 5th gets sent out. Now let's say te result is 50. Who is getting credit? All 5 of them?

---

Metod ...

>
> let's say we've got the following 4 results: 48, 49, 51, 52. They are groupped
> in pairs and we don't have a consensus of 3. So the 5th gets sent out. Now
> let's say te result is 50. Who is getting credit? All 5 of them?
>

Depends on how the validator is programmed...

Still using my example-validator, only 3 of the results can be validated, and 50 must be one of them. Which of the 3 results that is validated really depends on which trio is checked by the validator 1st.


For actual seti-results using the seti-validator on the other hand, the answer of how many validated would be different...

Well, this seems to cause confusion all the time. SO, I made a trivial example set to show a conceptual view of the Results, Validation, and Quorum of Results ...

Feel free to tell me how wrong the example is. Of course, if you don't have a good clear way to improve it I am just as free to ignore the complaints ...

:)

Enjoy
[edit]
forgot the link!

---