Your GPU makes only errors, please control it :)

http://setiathome.berkeley.edu/results.php?hostid=6137511

lovely, another anonymous user that cannot be contacted or identified

---

In a rich man's house there is no place to spit but his face.
Diogenes Of Sinope

And once again the quota system seems to be useless, however this time the max. tasks per day value is not simply frozen at some specific number but is apparently not going under 100 while counting up for each validated result (is was at 102 after two valid results when I looked at it the first time). With over 160 invalid/error results this host should be very close to 1 task per day, even if there were few valid results between that.

They really need to fix this, it's not working for many hosts here and also not on Milkyway, so it must be somewhere inside BOINC.

---

lovely, another anonymous user that cannot be contacted or identified

I'm curious how/why? I mean you need to give an email address to even have an account here, right? It's too bad that email isn't public. :-)

---

#resist

the account is anonymous so there is no means to contact them through a PM

---

In a rich man's house there is no place to spit but his face.
Diogenes Of Sinope

lovely, another anonymous user that cannot be contacted or identified

I'm curious how/why?

It's just a user who has hidden his/her computer(s).

Gruß,
Gundolf

lovely, another anonymous user that cannot be contacted or identified

I'm curious how/why?

It's just a user who has hidden his/her computer(s).

Gruß,
Gundolf

I suppose if my computer made that many errors I'd hide it too.
:-)

---

#resist

Before the icey finge of blame points its not me !

lovely, another anonymous user that cannot be contacted or identified


I'm curious how/why?

It's just a user who has hidden his/her computer(s).

Gruß,
Gundolf

I suppose if my computer made that many errors I'd hide it too.
:-)
____________
-Dave (Two)

Before the icey finge of blame points its not me !

No, it's an anonymous host,
6137511.
So, don't worry ;-)
This host shouldn't get the normal amount of tasks, unless it delivers valid
results, IIRC!

---

No, it's an anonymous host,
6137511.
So, don't worry ;-)
This host shouldn't get the normal amount of tasks, unless it delivers valid
results, IIRC!

In theory yes, unfortunately the quota system is (once again) not working for this host, it's allowed to get 100 tasks per day all the time and somehow it has even got 845 today, as you can see on the host's application details page.

---

No, it's an anonymous host,
6137511.
So, don't worry ;-)
This host shouldn't get the normal amount of tasks, unless it delivers valid
results, IIRC!

In theory yes, unfortunately the quota system is (once again) not working for this host, it's allowed to get 100 tasks per day all the time and somehow it has even got 845 today, as you can see on the host's application details page.

Returning errored work units is different than having work units marked as invalid after being compared to a wingman.

---

Given the limited bandwidth available and the abilities to analyse data, you would have thought there would be a way to track such a complete waste of bandwidth and stop giving it work until it sorts out its ability to compute valid results.

Sure we will all get an invalid result occasionally, either from bad data or a temporary host-side glitch. So I'm not saying that an invalid result alone should cause one's allocation to be lowered. However there should be some comparison done with valid V invalid results, that affects the allotment and takes it right down to a minimum in cases like this.

It is simply wasting valuable resources that others could put to good use. The system could then send a notification to the host as to why their allotment is reduced.

Len

---

I think I am. Therefore I am. I think.

No, it's an anonymous host,
6137511.
So, don't worry ;-)
This host shouldn't get the normal amount of tasks, unless it delivers valid
results, IIRC!

In theory yes, unfortunately the quota system is (once again) not working for this host, it's allowed to get 100 tasks per day all the time and somehow it has even got 845 today, as you can see on the host's application details page.

I've got one that is having problems with AP tasks, 74 of them. host 4840320, AP tasks But still allowed to d/load 100/day, probably because it processes MB tasks ok.

Looks like another modification needed in BOINC, so that it can stop downloads by task.

I've got one that is having problems with AP tasks, 74 of them. host 4840320, AP tasks But still allowed to d/load 100/day, probably because it processes MB tasks ok.

Looks like another modification needed in BOINC, so that it can stop downloads by task.

The quotas have been per app_version since April 2010. But the basic 100 comes from a single setting which applies to all kinds of tasks. Obviously if 100 is reasonable for MB, something like 10 would be for AP.

The real issue has always been how quickly the quota should grow. The present logic is a reported "success" doubles it if it is below 100 (capped to 100). Only errors recognized by the science application or core client can reduce the quota below the basic setting, since invalid tasks are reported as successes.

There have been several discussions on the boinc_dev mail list about the quota mechanism, but it remains in the condition that it can only protect against hosts which report all tasks from an app_version as errors.

                                                                 Joe

I've got one that is having problems with AP tasks, 74 of them. host 4840320, AP tasks But still allowed to d/load 100/day, probably because it processes MB tasks ok.

Looks like another modification needed in BOINC, so that it can stop downloads by task.

The quotas have been per app_version since April 2010. But the basic 100 comes from a single setting which applies to all kinds of tasks. Obviously if 100 is reasonable for MB, something like 10 would be for AP.

The real issue has always been how quickly the quota should grow. The present logic is a reported "success" doubles it if it is below 100 (capped to 100). Only errors recognized by the science application or core client can reduce the quota below the basic setting, since invalid tasks are reported as successes.

There have been several discussions on the boinc_dev mail list about the quota mechanism, but it remains in the condition that it can only protect against hosts which report all tasks from an app_version as errors.

                                                                 Joe

So this host still gets 100/day, of course, as he gets at least three "successes" because the was too much blanking.

The real issue has always been how quickly the quota should grow. The present logic is a reported "success" doubles it if it is below 100 (capped to 100).

That basically means 1 out of 50 results must be reported as success for to keep it at 100 in the long term. Waaay to little IMHO, 1 down for each error, 1 or max. 2 up for each success, I think 50% success is not too much to expect.

Only errors recognized by the science application or core client can reduce the quota below the basic setting, since invalid tasks are reported as successes.

There have been several discussions on the boinc_dev mail list about the quota mechanism, but it remains in the condition that it can only protect against hosts which report all tasks from an app_version as errors.

Why that limitation? Each time a result is marked invalid, the count for "censecutive valid results" is reseted, it schoud not generate much load on the servers nor should it be hard to implement, that the max. tasks per day is decreased by one.

Still it does not explain, why a host limited to 100 tasks per day (for a specific app) is able to get over 800.

---

So this host still gets 100/day, of course, as he gets at least three "successes" because the was too much blanking.

No, the host reports them as success, that all of them are invalid does not matter for the quota system. Only results reported as errors decrease the qouta, at least that's how I understand Joe's explanation.

---

With the host I reported if you look in Application details it is recorded;

AstroPulse v6 6.01 windows_intelx86
Number of tasks completed 0
Max tasks per day 101
Number of tasks today 1
Consecutive valid tasks 1
Average turnaround time 0.00 days

One success today but that is a "too much blanking"

Non of the other are recorded. The big problem there, IMO, is not counting the tasks completed when they are errors. Because the host has "completed" at least 74 tasks, but all are errors or "too much blanking". There should be some mechanism to spot this and decrease "Max tasks per day" and "too much blanking" should not increase "Max tasks per day".

...
Still it does not explain, why a host limited to 100 tasks per day (for a specific app) is able to get over 800.

For GPUs, the basic quota is multiplied by the project's gpu_multiplier setting, 8 for this project. So although the "Max tasks per day" displays the internal unmultiplied value, 100 corresponds to an actual 800 quota for the cuda_fermi app version.

Why it has somewhat more than 800 sent "today" is probably because it has about 19 tasks which did validate in the last 24 hours, so the quota was probably at 808, 816, or maybe as much as 952 (119 * 8).

                                                                  Joe

To me it looks like http://setiathome.berkeley.edu/show_host_detail.php?hostid=3378825 has a bit of a problem. About 11,000 WUs about to be invalid is my guess.