I have just heard of this 'new' feature. It would be nice if someone could post all about it on the Technical pages so that other could be aware of it......or have I missed an announcement?

---

> I have just heard of this 'new' feature. It would be nice if someone could
> post all about it on the Technical pages so that other could be aware of
> it......or have I missed an announcement?
>
Yes, I'd like to have it explained as well. I knew there was a limit, but didn't know what it was or how it was determined.

I haven't seen any announcement, maybe we both missed it.

tony

Mainly to make sure a bad host doesn't trash thousands of results in a short time, a daily_quota of how many "results" possible to download per computer per day was added during beta. How many downloads in a day is reset at midnight, server-time. This currently means 07:00 GMT for seti.
In seti this limit was 50, but increased to 100 some time ago.
Resently the daily quota also started to take #cpu's on a host into consideration, but uses an upper limit of 4 cpu's. For seti this means 100-400 wu/day.

Some computers seems to have permanent problems for different reasons, so another change was added:

1; For every error/past deadline, decrease the computers daily_quota by 1.
2; For every successfully reported result, double the computers daily_quota.
3; Never decrease below 1, or above the computers default daily_quota.

> > I have just heard of this 'new' feature. It would be nice if someone
> could
> > post all about it on the Technical pages so that other could be aware of
> > it......or have I missed an announcement?
> >
> Yes, I'd like to have it explained as well. I knew there was a limit, but
> didn't know what it was or how it was determined.

Note Ingleside's explanation.

This is a very good feature for those who are active, dedicated crunchers because it reduces the delay caused by "bad" machines.

A broken machine that has been fixed should return to full quotas pretty quickly, and there is only a small penalty for an occasional hiccup.

---

Surely something as important as this deserves a better 'press'. The explanation above is pretty comprehensive, but, this thread will sink into oblivion and be lost.

News of this magnitude deserves better treatment, either by being in the Technical pages on the Home Page, or, why not have a specific Read Only Members News Forum, instead of it being buried in here?

---

> Surely something as important as this deserves a better 'press'. The
> explanation above is pretty comprehensive, but, this thread will sink into
> oblivion and be lost.
>
> News of this magnitude deserves better treatment, either by being in the
> Technical pages on the Home Page, or, why not have a specific Read Only
> Members News Forum, instead of it being buried in here?
>

Only .00005% of the volunteers will read the news......

---

Semper Eadem
So long Paul, it has been a hell of a ride.

Park your ego's, fire up the computers, Science YES, Credits No.

> > Surely something as important as this deserves a better 'press'. The
> > explanation above is pretty comprehensive, but, this thread will sink
> into
> > oblivion and be lost.
> >
> > News of this magnitude deserves better treatment, either by being in the
> > Technical pages on the Home Page, or, why not have a specific Read Only
> > Members News Forum, instead of it being buried in here?
> >
>
> Only .00005% of the volunteers will read the news......

... and only .0001% will even notice the limit.

---

> Surely something as important as this deserves a better 'press'. The
> explanation above is pretty comprehensive, but, this thread will sink into
> oblivion and be lost.

In Ingleside's post, he also covers how this policy has been tuned, and on the developer's list, there is a discussion of a whole new scheduler that will try to do a better job of assigning work.

So, the rules are not cast in concrete, they are at best cast in Jello.

Maybe sinking into oblivion isn't a bad thing.

---

People who have found seeming problems in their # of WUs downloaded, but have not created many errored or overdue WUs should probably know the entire equation.

[Requested_work] = [connect_every_xx_days] * [secs_per_day] - [secs_in_queue_on_host]

Next, requested work is adjusted:

[Requested_work] = [Requested_work] * [percent_of_each_24_hours_this_host_runs_boinc]

So, if your computer is on 10 hours each day, and programs you are running (like games, etc) use 2 hours of those 10, the value would be 8 hours/24 hours or 33%.

The code that calculates this has some hiccups and may produce a really wrong value occasionally. The only way to fix this is to edit the file "client_state.xml" in your boinc folder.


Next it is adjusted again:

[Requested_work] = [Requested_work] * [project's_share_of_BOINC_time]

If there are more than one projets on the host, and one has 30% and the other 70% of the CPU time, this is the value used here.

> People who have found seeming problems in their # of WUs downloaded, but have
> not created many errored or overdue WUs should probably know the entire
> equation.
>
> [Requested_work] = [connect_every_xx_days] * [secs_per_day] -
> [secs_in_queue_on_host]
>
> Next, requested work is adjusted:
>
> [Requested_work] = [Requested_work] *
> [percent_of_each_24_hours_this_host_runs_boinc]
>
> So, if your computer is on 10 hours each day, and programs you are running
> (like games, etc) use 2 hours of those 10, the value would be 8 hours/24 hours
> or 33%.
>
> The code that calculates this has some hiccups and may produce a really wrong
> value occasionally. The only way to fix this is to edit the file
> "client_state.xml" in your boinc folder.
>
>
> Next it is adjusted again:
>
> [Requested_work] = [Requested_work] * [project's_share_of_BOINC_time]
>
> If there are more than one projets on the host, and one has 30% and the other
> 70% of the CPU time, this is the value used here.

... and this is seperate from the server-side limits in Ingleside's post?

The equitable allocation of work is complex, isn't it.

---

.o0(Smile and nod... admit no guilt... just walk away calmly... and don't mention the WU-killing box you've got...)

---

> >
> > Only .00005% of the volunteers will read the news......
>
> ... and only .0001% will even notice the limit.
>

And, if you have a welltuned box with no cache, no download, upload, and processing errors, you wouldn't notice at all!

---

"I'm trying to maintain a shred of dignity in this world." - Me

>... and this is seperate from the server-side limits in Ingleside's post?

>The equitable allocation of work is complex, isn't it.

Yes, this is the number of seconds your machine "requests".

Will the server actually give you that much work??? -- refer to Ingleside's post ;)
------------------

>.o0(Smile and nod... admit no guilt... just walk away calmly... and don't mention the WU-killing box you've got...)

What you mean this old box?

Nah thats just the fruits of thousands of lines of optimized code ;)

>>.o0(Smile and nod... admit no guilt... just walk away calmly... and don't mention the WU-killing box you've got...)
> What you mean this old box?
No... I mean this old box.

I guess I mentioned it, didn't I.

.o0(Danger, NeoAmsterdam! Change the subject! A distraction - Quickly!)

So... what's it like to have 4.2 perfect cobblestone machines??

---

> I guess I mentioned it, didn't I.
>
> .o0(Danger, NeoAmsterdam! Change the subject! A distraction - Quickly!)
>
> So... what's it like to have 4.2 perfect cobblestone machines??

Hmm, Im gonna guess that box has a very low max WU ;)

And that other machine is more like 7.5 cobblestones :P