Your current settings Allow up to ~10000 work units per day!

This is taken from the linked page from the post above this post :
"Maximum daily WU quota per CPU : 9948/day"

!!!!!!!!!!!!!!!!!!!!!
Tweak it down to 100 -- for everyone.
!!!!!!!!!!!!!!!!!!!!!

That will probably be a better fix, and the dodgy computers will drop out...

No fuss, no muss.

This will not be the first project to do this.

Your current settings Allow up to ~10000 work units per day!

This is taken from the linked page from the post above this post :
"Maximum daily WU quota per CPU : 9948/day"

!!!!!!!!!!!!!!!!!!!!!
Tweak it down to 100 -- for everyone.
!!!!!!!!!!!!!!!!!!!!!

That will probably be a better fix, and the dodgy computers will drop out...

No fuss, no muss.

This will not be the first project to do this.

Lots of fuss and muss. Many with fast GPUs will drop out. A machine with 4 5870 cards can do in the neighborhood of 4500 WUs/day. What really needs to be done is to untie the WU quota from the number of CPU cores completely. CPU cores have nothing to do with output in this project.

What really needs to be done is to untie the WU quota from the number of CPU cores completely. CPU cores have nothing to do with output in this project.

That is highly unlikely to happen for all the reasons discussed here many times over the last 2 years.

---

Go away, I was asleep

Lots of fuss and muss. Many with fast GPUs will drop out. A machine with 4 5870 cards can do in the neighborhood of 4500 WUs/day. What really needs to be done is to untie the WU quota from the number of CPU cores completely. CPU cores have nothing to do with output in this project.

not everyone has access to gpu's i use virtual machines to crunch so only have cpu's to use and even if i used my host with access to a HD5850 due to faulty amd drivers or card i don't know i would probably end up reporting failures all the time due to driver not responding error's so i think the WUs/day should depend on reliability as im sure if its changed people will report having 10000gpu's instead of 10000cpu's

---

I don't understand the point here. If users return invalid results the WU gets issued again if necessary. In fact, as all the serious BOINC projects list as having more crunchers than work, these results aren't even on the grid. If one result is bad, the other 8 are good. (they only needed 3, but they gotta keep us busy)
Why are you all getting your panties into a twist over this and wasting the time of the people running the project?

---

;

Because the people running the project want to know of hosts who are running out of control trashing WUs, and would like to be notified when one is spotted. Its a massive waste of server assets and disc space when tens of thousands of WUs - arguably hundreds of thousands - a day get trashed for no other reason than extremely poor local PC housekeeping.

One of the major reasons for restriction on the number of WUs being sent to each cruncher is disc space issues, a major factor in that is tracking and storing a WU and its different stages in being crunched. To do so for hundreds of thousands that end up being trashed - whether by constant error or by-passing restrictions on holdings and timing out, both are the same effect - is not the best idea on the block, and anything that can be done to eliminate that - despite the pain of twisted pants - can only be a good thing.

GMC-thanks for the thoughts but the project maintains strict rules about how many WU's people can have. If people are running an app that allows someone to hoard WU's, it is not only unfair to other crunchers but could be giving false reports that skew project results.

---

If users return invalid results the WU gets issued again if necessary

Can You remember the days when MW was down three or four times a week? Stuff has done their job to optimize the project and reduce data traffic, now the crunchers need to do their part.

(they only needed 3, but they gotta keep us busy)

Can You remember the days when some people compiled a app to crunch in single precision (faster) and bad wu's validated against bad wu's and good ones did not validate? It's up to the project to decide how many results are necessary.

Looking at the application pages of all that hosts I think that the starting value for "max tasks per day" is waaay to high. Since here at MW most returned results get validated immediately, even for fast GPUs a starting value of 1000/GPU should be more than enough, specially considering the fact, that every valid result increases it by one and occasional errors don't reset it to the starting value like on many other projects, but only decrease it by 1. For CPUs 100 per day should be enough.

That way those hosts should be down to 1WU/day a lot faster.

---

If users return invalid results the WU gets issued again if necessary

Can You remember the days when MW was down three or four times a week? Stuff has done their job to optimize the project and reduce data traffic, now the crunchers need to do their part.

(they only needed 3, but they gotta keep us busy)

Can You remember the days when some people compiled a app to crunch in single precision (faster) and bad wu's validated against bad wu's and good ones did not validate? It's up to the project to decide how many results are necessary.

Thank you Mr. Obvious. as to the '3'...it was 'pick a number' the 'tell me 3 times' model is the most common. The truth is, they probably get 5 identical verifiable results back from every WU.
As to data traffic..we're streaming HD movies these days..are you seriously gonna tell me data traffic of this nature is still an issue? LOL Server load? come ON..computing power is so dirt cheap these days it's pretty much made BOINC obsolete altogether.

The simple fact of the matter is, with a volunteer project of this nature you are NEVER going to control the users input the way we're discussing here. It is Simply Not Going To Happen without enough effort on the part of the project people to negate the entire benefit of the volunteer project.

The responses to my comments above are all non issues due to the fact that most of the 9 or 12 people doing the same WU return good results. The bad stuff should be going into the trash without human effort. If the users can really jam up the works, I submit the server side of the project isn't set up properly.

---

;

I'm not follow you.

If I produce bad results I want to know it so that I, if possible, have a chance to correct it or maybe chose an other project that works better with my computer.


To have a the computer that constantly produce errors or no results at all is just a stupid waste of resources, both his own and the projects.

As to data traffic..we're streaming HD movies these days..are you seriously gonna tell me data traffic of this nature is still an issue? LOL Server load? come ON..computing power is so dirt cheap these days it's pretty much made BOINC obsolete altogether.

Yes, network load is a problem. If you need something to read about problems related to that, go to Seti forums. And computing power is not cheap, if you want to know what it costs, that is a good place to start.

The responses to my comments above are all non issues due to the fact that most of the 9 or 12 people doing the same WU return good results.

Have you ever seen a WU done by that many people? Most of them validates after the first result, some needs 2, if some errors occur than eventually more. Since MW sends out the next task for a particular WU after the first result was reported or timed out, it's highly unlikely, that you will ever see a WU successfully crunched by 9 people (that's btw maximum, 12 not possible).

---

As to data traffic..we're streaming HD movies these days..are you seriously gonna tell me data traffic of this nature is still an issue? LOL Server load? come ON

If this project had Netflix' or Youtube's hardware budget I expect things would be smoother. Don't hold your breath though. ;)

..computing power is so dirt cheap these days it's pretty much made BOINC obsolete altogether.

I really don't follow that one. BOINC exists because little projects like MW can't afford computing power. They solicit it from us.

---

Just something, that the project admins should eventually check: on some hosts the quota system seems not to work, i.e. the value for "max tasks per day" is frozen at 10000.

Examples:
Host 287332
Host 256358
Host 216388

Eventually it can be something user account related, if you look at the FreeBSD machines of this user, they are all at 10000 and have never returned a valid result, at least not with the app listed on the host application page.

I think having a workling quota system is the best way to stopp such hosts from trashing WUs, as can be seen on this two: 82319 & 233613. Here is even one, that ATM can't get even a single WU: 184480.

_

---

I reported this one http://milkyway.cs.rpi.edu/milkyway/show_host_detail.php?hostid=27701 23 days ago.

He still have 3090 wu's
He still download more than 100 wu\day

And he still have 'Number of tasks completed' = 0
Yes I know the staff is 'working on it' and that it's not your fault Blurf but is it any point at all to report an 'Owner Anonymous'?

I reported this one http://milkyway.cs.rpi.edu/milkyway/show_host_detail.php?hostid=27701 23 days ago.

He still have 3090 wu's
He still download more than 100 wu\day

And he still have 'Number of tasks completed' = 0
Yes I know the staff is 'working on it' and that it's not your fault Blurf but is it any point at all to report an 'Owner Anonymous'?

Thank you for not assigning fault.

Fact is this is a new process we're trying to use to deal with people using old expired apps or hoarding WU's. As with any new process, it needs to evolve and will do so over time. I am working with the other admins so that I can have more direct control over this process (since it was my brainchild) and more access to address these issues. We will see what happens....but I say yes, please include them but understand they are more difficult to address.

---

I am sure the Annon. computers atleast could be blocked/removed or equivalent.

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

I believe the main reason is that the staff simply does not have the recourses and it can be both security and legal issues regarding giving the administration more access to handle the system and maybe this issue is no big problem after all.

I believe the main reason is that the staff simply does not have the recourses and it can be both security and legal issues regarding giving the administration more access to handle the system and maybe this issue is no big problem after all.

Someone has access, Travis atleast. That was all I ment.

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

Due to some personal stuff going on, my spare time is really limited this week. I'm taking a few days off from working on these. Please keep listing them and I'll get back to them early next week or maybe Sunday.

One slight procedural adjustment-don't worry about the anonymous ones. They're too difficult for me to personally address.

---