My own understanding of the 2/3 or even 2/2 quorum is, that it is needed to enable the amount of work produced by 7 beams with horizontal and vertical polarisation. Or another way each period of timed scanned will produce 14 times as many units.
So even if they take 70% of the time to process, compared to the present enhanced units. If that is true it will take 10 times longer to crunch the data coming from Aricebo, so going to 2/2 seems logical to make it only 5 times longer. And hope future hardware developments and software optimisation like we have seen over the last 8 years will allow us volunteers to catch up again.

Thank you for the clarification:-)
But, correct me if I am wrong, those won't be run by a tape splitter. Instead they will be split from a harddrive instead, thusly increasing the splitting speed?

Don't know about that, logic says maybe!

My own understanding of the 2/3 or even 2/2 quorum is, that it is needed to enable the amount of work produced by 7 beams with horizontal and vertical polarisation. Or another way each period of timed scanned will produce 14 times as many units.
So even if they take 70% of the time to process, compared to the present enhanced units. If that is true it will take 10 times longer to crunch the data coming from Aricebo, so going to 2/2 seems logical to make it only 5 times longer. And hope future hardware developments and software optimisation like we have seen over the last 8 years will allow us volunteers to catch up again.

Thank you for the clarification:-)
But, correct me if I am wrong, those won't be run by a tape splitter. Instead they will be split from a harddrive instead, thusly increasing the splitting speed?

Reading the data into memory is a very small fraction of the splitting time, just as reading the WU is a small fraction with the S@H applications we run.

After Eric added filtering to reduce the effect of the radar noise pulses, he noted in the Beta NC forum that it had slowed splitting significantly, so he had increased the number of splitters.

                                                               Joe

So what is actually needed is a Megalodon splitter server of stunning proportions?

Can (or could) Alfa data be split by a processor? If so it seems like it would take notime to split each period of the whole bandwidth of radio signals. I don't know how the past splitters (for the stick receiver) were constructed. Maybe it took a long time to transfer data from the tape to whatever held the data to be assimilated by the splitter. It seems like, once the entire bandwidth were written to the medium to be handled by the splitter, a splitter processor could divide up that band in notime.

---

Don't know about that, logic says maybe!

That sounds like an answer out of one of those "Magic 8 balls".

---

LOL....

I'm taking the pragmatic viewpoint. The team has long said there might come a time when there wasn't enough work to go around for everyone all the time, regardless of the reason.

That day has come! ;-)

Alinator

It may well be that the answer to server overload problems is this.........

Only connect to server when two results are completed!

This should not present any problems to those of us that are running the slowest of machines.

Surely the simplest answers are the best.

Your input on this is most welcome.

Graeme.
www.boincuk.com

---

Personally, I think we still have some kind of database access problem. Consider:

1) Slow Result/WU creation rate. I've seen much higher creation rates before. A 6th splitter hasn't helped.
2) Slow Validation rates. Even if the quorum has been reduced from 3 to 2, the validators should be able to keep up.
3) Slow reponse when reporting Results. It takes much longer to report Results now than it used to.

To me, this all points to possible database problems. Non-optimized queries, missing indexes, and/or low database parameters.

---

1) Slow Result/WU creation rate. I've seen much higher creation rates before. A 6th splitter hasn't helped.
2) Slow Validation rates. Even if the quorum has been reduced from 3 to 2, the validators should be able to keep up.
3) Slow reponse when reporting Results. It takes much longer to report Results now than it used to.

the Result/WU creation rate doesn´t seem to be that bad:


- but you are right with the validators...

mic.

---

mic.

An oddity. Running two boxes..one windows and one linux. last couple of days the linux box has had no trouble up & downloading WU's. The windows machine on the other hand dithers around and gives me "no work from project" and "deferring". Either ET is scared of my mighty windows machine or doesn't care for MS (g)...j

running three boxes all windows.
two with winxp one with Vista 64.
No trouble getting work.

---

With each crime and every kindness we birth our future.

All I have been getting for the last 2 days on all machines is

Mon 23 Apr 2007 07:52:31 BST|SETI@home|Scheduler request failed: HTTP gateway timeout

Anybody else getting this?

Nairb

---

Seems like Matt started the turbo on the validators!

From 170k to some 90k in just a couple of hours...

RAC going up - without crunching (no work)


Time for the turbo-splitters!!


mic.

---

mic.