Other than that I just cant think of any reason that would benefit the project letting people load up 14 days of cache if units need to be returned in 14 days, but I can think of a whole bunch of neg's.
=========

Your right Nick, for quit awhile now there really hasn't been a reason for anybody to be loading up 14 days worth of WU's. Back when BOINC Seti first started out in was normal for me to cache 8-10 days worth because the Server was forever going down for days on end, so you never knew when you would get any more WU's to do.

But anymore the Server is pretty stable and if it does go down now it's only for a day or so at the most, not to say it won't go down longer than that some time in the future though. 3-5 days of WU's should be plenty enough for anybody I would think.

For anyone with a permanent connection, using a 2-days cache isn't a problem. But, some users can't or won't let their computer(s) be connected all the time, and if they're not accessing their computers daily they therefore needs a larger cache than 2 days.

Since SETI@home-wu isn't time-critical, some users using 1 day or 13 days isn't really a problem, the wu was probably recorded 6 months to 6 years before anyway.

Also, now they're issuing the same wu to 4 different users, 1 of them having an error doesn't slow the rest down in getting credit, and if this user returns after the deadline normally the only one not getting any credit is the user himself.

BTW, limiting how many days to cache wouldn't change anything as far as hosts with download-problems or just a little bit too much overclock so all results error-out, they will still download 100 wu/day.

Users downloading a little bit too much to keep below deadline on the other hand will probably decrease but if this isn't a too outspread problem, all the users "needing" a 10-day-cache starting to complain if decreased to 5 days would maybe be a bigger problem...

> Just been looking thru my `pending` WU's. Noticed one is really lagging so had
> a look thru the other hosts crunching it, and found this guy has got over 300
> WU's downloaded for 1 of his machines.

There is a known bug that causes WUs to download and get lost if BOINC doesn't have proper permissions.

This happens when someone goes through the computer lab at school and sets up BOINC on all the lab computers.

---

@Benher
> My suggestion (and supplied source code) was for 20 WUs per CPU (or pretend
> CPU ala HT), but wasn't adopted.

Too bad, Benher. But thanks for trying! :)

IMO, 20 WUs per CPU would have been the by far best solution, catering for fast N-way machines AND restricting rogue ones much better than the simple increase to 100 per host.

---

> Too bad, Benher. But thanks for trying! :)
>
> IMO, 20 WUs per CPU would have been the by far best solution, catering for
> fast N-way machines AND restricting rogue ones much better than the simple
> increase to 100 per host.
>

This suggestion works, till someone installs on a new computer or gets assigned an upgraded application, and one of the application-files fails to download, often meaning 20 wu just errored-out...
If this is a new install, or someone catched this error, someone just hit "detach", maybe before the error is even reported meaning must wait 14 days before eventual re-issue.

Ok, new installs normally doesn't get 20 wu in 1st asking, but still if BOINC is looked on as too much of a problem to use many will either switch to another project or stop any form of distributed computing altogether...

Ok, new installs normally doesn't get 20 wu in 1st asking, but still if BOINC is looked on as too much of a problem to use many will either switch to another project or stop any form of distributed computing altogether...
=========

I agree Ingleside, If my PC's where constantly running out of work from Seti I would just say the Hell with it and quit running the Projects all together. And don't anybody tell me to go run the other Projects either, I will on occasion run the other Projects but Seti is my preferred Project right now and the only one I will try to run if work is available ...

> > The cache should be limited to 5 days maximum.
>
> Why?
> As long as the Work Unit results are returned within 14 days what's the
> problem?
>

When will we ever see a 7 day outage?

Besides the system downloads double so your work units should stay between 5 and 10 days. I personally was using .2
and had no problems with the 12 hour drop out a few days ago.
What is a loss of 8 hour over at least 1/2 year 24/7?

I did set mine up to 1.5 days for the upcoming outage, but will set it back down to .2 again after they are running again. You don't know how long the power company is going to have the power off.

Hopefuly they can estimate the time better.

---

Red Bull Air Racing

Gas price by zip at Seti

Also look at this:

Can we stop a Wu-killer like this?
http://setiweb.ssl.berkeley.edu/forum_thread.php?id=7693

alo_dk

@Ingleside
> This suggestion works, till someone installs on a new computer or gets
> assigned an upgraded application, and one of the application-files fails to
> download, often meaning 20 wu just errored-out...
> If this is a new install, or someone catched this error, someone just hit
> "detach", maybe before the error is even reported meaning must wait 14 days
> before eventual re-issue.
>
> Ok, new installs normally doesn't get 20 wu in 1st asking, but still if BOINC
> is looked on as too much of a problem to use many will either switch to
> another project or stop any form of distributed computing altogether...

I don't follow.

After a detach/reattach, you get a fresh daily quota. (I've tried on a 80 WU/day SMP getting starved @ 50, and it works. Downside is having to merge hosts afterwards, and getting the RAC reset.)
The 14-day wait before the same WUs are reissued exists no matter the quota. From the client side, the delay would be the quota period of 1 day (without user intervention), not 14.

But then again, I didn't quite understand what you meant.

However, don't focus too much on the number 20. IMO, a per-CPU daily quota of *any* size would be better than a per-host quota scheme.

---

point one) Seti has 250 to 500,000 wus ready to send at all times.
2) could be side affect of other projects when you change cache size its for all projects. mine is specialized for predictor right now. i get the right amount of those but to do that i have way too much seti wus my self.
3) crappy seti benchmarks completion eta #'s. my laptop tells me ninteen hours til finish but takes 25 yet the other four take what they tell me plus minus at most 15 minutes. predictor actually takes half of the 20 hour time to finish count.
4)wu burps. remember that server crash that took about a week and a half when seti was the only boinc'er. i was on a 14 day connection interval. you no chache'ers were out and i had work through the whole thing and only 2 wus out of 35 didn't get in on time.
5) dial up
if they could figure out how to do it put a controller that averages how your machine crunches the wus and asks for what the machine knows it can crunch not what the user tells it to. like my machine needs 16 predictor wus to last 1 week.
but to last that same week seti only needs seven but it should be able to have fourteen and stay within its 2 week deadline. its not allowed to though because my machine has to run on a one week interval for predictor.

---

~boinc its not the credit or satisfaction its the screensavers~
S@h Berkeley's Staff Friends Club ©members

If they don't return the result on time they don't get credit.
I can wait to get credit untill the require results are return and get validated.
If they load up pushing the 14 day limit and there computer crash or whatever, in the long run they are the one that loses.

One should ajust their connect ever xx days so all the results of all their projects are returned before the deadline.

The new system is suppost to limlt the wu sent to a user if their results are not turn in on time. This is being work on, again the Boinc system is still being modified to resolve these kind of problems

---

Fred
BOINC Alpha, BOINC Beta, LHC Alpha, Einstein Alpha

> When will we ever see a 7 day outage?

As was mentione din a nother thread, Seti classic did suffer a 7 day outage a few years ago.
4 days wasn't unusual.

---

Grant
Darwin NT

>
> I don't follow.

Let's try re-frase it...

In seti, you can at most get 20 wu/RPC. If you've got a 1-cpu doing 10 wu/day and caches 4 days or something, you'll get this max.
If for any reason 1 of the application-files isn't correctly downloaded, ALL wu assigned in this RPC is marked as error and normally reported back, atleast v4.13 doesn't re-try downloading application-files as it really should have done.

Anyone getting a new application, either due to upgrade or new install, can with a per-cpu-limit of 20 risk not getting any work this day if any connection-error, and the only way to solve this problem is to detach/reattach.

If the limit is example 30 instead, you can do another RPC and often manage downloading the last application-file also. If needs to reset or detach/re-attach, all files must be re-downloaded and especially if dialup the chances to get 1 corrupt file is much higher then downloading many files than if you only download one file.

>
> After a detach/reattach, you get a fresh daily quota. (I've tried on a 80
> WU/day SMP getting starved @ 50, and it works. Downside is having to merge
> hosts afterwards, and getting the RAC reset.)

Yes, you get a new quota, but with todays limit of 100 wu/day per host you don't need to detach to get any work if one or two download-errors.

> The 14-day wait before the same WUs are reissued exists no matter the quota.
> From the client side, the delay would be the quota period of 1 day (without
> user intervention), not 14.

Download-errors is normally reported as such in next RPC and is therefore often re-issued nearly immediately, but since the client will try finishing downloading all files even after getting an unrecoverable error, this can take some minutes atleast on dialup. If you anyway is forced to detach to get any work this day, you'll of course do this immediately and not wait till any errors is reported.

>
> But then again, I didn't quite understand what you meant.
>
> However, don't focus too much on the number 20. IMO, a per-CPU daily quota of
> *any* size would be better than a per-host quota scheme.
>

The daily quota is mainly to stop runaway hosts either erroring-out every wu, or never returning anything. Since both BOINC servers, clients and applications can have ocassional problems, any quota must be chosen in such a way that most users will not run into this limit and be out of work.

As tried to show, this means the quota must be larger than 20, but how much higher? At 30 per cpu, you can have 1 download-error and crunch 10 wu, for most this should be large enough. :)

But, with 30 wu/day per cpu, what if the 32-way atleast earlier running Predictor@home suddently develops a problem, grabbing 960 wu...

I have downloded 100 wu's.Simply because there is an outage coming and 100 do not last me very long.I do about 16-18 a day.And downloded 100 incase the outage lasts longer than it does.I normally download 20 at one time and have the thing connect every day but changed it after reading about the coming outage.I also wanted to see how many I could download etc for when I go away.My last hol I left it connected but when I got home my connection had failed and seti had stopped running.So next time I will download 160 wu's over 2-3 days before going away so I have enough wu's for 10 days and then can disable network accesss.

---

......In Space No One Can Hear You Scream......

I have downloded 100 wu's
=========

Hoarder ... ;)