Martin G. Diehl wrote:

Martin wrote:

[...]

_BIG_ QUEUES ARE BAD FOR SETI@HOME!!!

unsupportable conclusion

On the contrary, that statement is very supportable. Think further... FalconFly's very good answer should give you a few clues... (Or just do a google for some good past discussions.)

If your queue delays you returning the result for a WU from the TIME OF DOWNLOADING THAT WU for too long, that result is near useless.

Not necessarily true ... that "late" WU result could be the tie-breaker. 

Very true... However, how late is too late?

(And very expensive electricity to just increment your WU count.)

Also, the s@h server must keep a pool of WUs that matches the pool of WUs temporarily lost in everyone's queues, to then later check if enough results have been returned before clearing a particular WU from the pool.

False.  The S@H WU server does not wait for any results before clearing a WU -- it sends each WU to several clients initially.  This has been known for about 2 years. 

Your "False" is wrong. Your following statement however is true...

Big user queues increase the workload on the s@h database and server.

False ... no evidence for this conclusion. 

Try again... Think how s@h works (for the SCIENCE -- big hint (;-))

As to how big a queue is reasonable?...

Nobody knows. 

An easy calculation given the server specs vs running stats. We on the outside can make some good educated guesses.


...
Warning... Answer spoiler warning...

...



...






...







...





...












...!


If s@h was just counting returned WUs and then throwing them away to just award one point per WU, then your apparent assumptions and comments would be completely correct.

Reality is -- Those WUs which remain after you have cross-checked for at least 3 returns or more. (And the database bashing and WU disk space required to support that for 600 000 active users multiplied by the size of their queues.)


Onwards with a more efficient (small queue delayed) crunch...

Regards,
Martin