By now, both SETI and us users (all -- not just gasbuddy) should be painfully aware that massive downloading of WU's and uploading of results is mainly a hardware problem. The volume of network traffic is overloading Seti@H BOINC's servers and storage capacity.

I think they should run a script reseting all users to no more than 1 days work and lock them there until they are ready to try their latest and greatest solution or hardware upgrade. They can then restore everyone's prefrences and let us try and break the system again.

Frankly, I do not see the sense in caching WU's at all. Downloading more than a days work at a time, while great when the system is "up 'n' down"; will cause individual and group rankings to jump around in quantum leaps and bounds as large chunks of work are
processed and returned.

--Pete

thats a good idea, esp with people who have multiple computers
ttyl
Jeff (Nightowl)
All your answers in one spot:
http://setiweb.ssl.berkeley.edu/transition.php
=====
If you dont like Boinc, then go back to classic seti.

I don't know about one day but I would like to see BOINC projects able to enforce a maximum queue length. I know there are some people with special circumstances but this is one place I think the good of the project should come first. A reasonable max rule of thumb would be one day less than the average deadline or 13 days for seti.

John Keck
BOINCing since 2002/12/08

> I don't know about one day but I would like to see BOINC projects able to
> enforce a maximum queue length. I know there are some people with special
> circumstances but this is one place I think the good of the project should
> come first. A reasonable max rule of thumb would be one day less than the
> average deadline or 13 days for seti.

This does not quite work for slow computers or Predictor. The queue can be overfilled to double if one WU fills the queue less one second, the second WU will be downloaded, and the queue will be filled to double less 2 seconds. Predictor has a minimum deadline of 1 day, and therefore should have a max queue size of .5 day by my calculation or 0 days by your calculation. My calculation would give what might be in some cases an unreasonably short 7 days.

A slightly different way of doing this would be to have a max queue size enforced by the projects of say the minimum deadline - 1 day, 1/2 of the minimum deadline whichever is greater, and then not allow the client to ever overfill such that a WU cannot be calculated by the deadline for that WU. However, this may require too much calculation.

> > I don't know about one day but I would like to see BOINC projects able
> to
> > enforce a maximum queue length. I know there are some people with
> special
> > circumstances but this is one place I think the good of the project
> should
> > come first. A reasonable max rule of thumb would be one day less than
> the
> > average deadline or 13 days for seti.
>
> This does not quite work for slow computers or Predictor. The queue can be
> overfilled to double if one WU fills the queue less one second, the second WU
> will be downloaded, and the queue will be filled to double less 2 seconds.
> Predictor has a minimum deadline of 1 day, and therefore should have a max
> queue size of .5 day by my calculation or 0 days by your calculation. My
> calculation would give what might be in some cases an unreasonably short 7
> days.
>
> A slightly different way of doing this would be to have a max queue size
> enforced by the projects of say the minimum deadline - 1 day, 1/2 of the
> minimum deadline whichever is greater, and then not allow the client to ever
> overfill such that a WU cannot be calculated by the deadline for that WU.
> However, this may require too much calculation.
> <a> href="http://www.boinc.dk/index.php?page=user_statistics&project=sah&userid=9915">
>

Since the BOINC client runs a speed test on eevry lauch, you could use a formula based on that to let the system know when to experiance the work unit back and let slower system keep WU's longer. Or you could keep the history of the past few and use that to alow longer checkouts of some work units. You could then increase teh size of teh work units and lower the traffic because oyu dump the added connection over head (amount of actual data is the same, but you don't need the header info which while not a lot, is noticable with this amount of traffic).