Welcome to MilkyWay@home

Posts by Bill & Patsy

1) Message boards : Number crunching : Work Availability? (Message 24104)
Posted 3 Jun 2009 by Bill & Patsy
Post:
Can we maybe stop the GPU vs. CPU snipping, please, and keep the focus on server efficiency and performance? We understand the GPU-CPU differences of opinion, and IMO that "discussion" is at a stalemate.

Thank you.
2) Message boards : Number crunching : Work Availability? (Message 24027)
Posted 3 Jun 2009 by Bill & Patsy
Post:
Thank you, Travis!
3) Message boards : Number crunching : How to Get Work (Message 23828)
Posted 1 Jun 2009 by Bill & Patsy
Post:
Well, it's been about a day now and my modest RAC (from my little ol' laptop) has increased 40% - from 323 to 454. So the technique seems to be working. ;-)

One thing I've found is that my external optical mouse seems to have undetectable micro-jitter, I'm guessing from air currents caused by the laptop's cooling fan. I can't see it on the screen, but it seems to cause just enough error to make it very hard to keep the pointer tip on the sweet spot. I don't think a script would help to compensate. You just need to practice developing a very steady hand and a very sharp eye.

Hope this helps!!
4) Message boards : Number crunching : How to Get Work (Message 23819)
Posted 1 Jun 2009 by Bill & Patsy
Post:
I'm still trying to find the "Any" key ..............

It's right here:

5) Message boards : Number crunching : How to Get Work (Message 23741)
Posted 31 May 2009 by Bill & Patsy
Post:
I have found that if I position the tip of the mouse pointer arrow on exactly the point of the upper right corner of the Update button, then I get work from MilkyWay almost every time that I by press the button. But I have to be in exactly the right position for this to work.

Hope this works for you too.
6) Message boards : Number crunching : 3rd.in - optimized apps (Message 23636)
Posted 29 May 2009 by Bill & Patsy
Post:
zslip.com is a web site that hosts downloads for optimized applications which have been developed by third parties for MilkyWay@home crunching.

And just in case you can't remember that site http://www.creditsathome.com is impossible to forget.

Drat, I'd forgotten about that again. Thanks again Misfit for the link impossible to forget ;)

It never gave me any credits, said Project Unavailable:
29/05/2009 12:47:39 Fetching configuration file from http://www.creditsathome.com/get_project_config.php

Clever! ;-)
7) Message boards : Number crunching : Why is it so hard to get work? (Message 23511)
Posted 27 May 2009 by Bill & Patsy
Post:
Interesting that there seems to be a general consensus on what's "fair" to the GPU folks vis-a-vis the transition, but (as evident from the continuing argument) a lingering wish by some that using scripts to push to the front of the line (along with causing collateral damage) could also be "fair". Wouldn't it be agreed that the former reflects regard for the effects of actions on fellow participants (good), while the latter reflects disregard for the effects of actions on fellow participants (you decide)?
8) Message boards : Number crunching : Why is it so hard to get work? (Message 23407)
Posted 26 May 2009 by Bill & Patsy
Post:
Ice, the most recent postings from banditwolf and Brian were platform independent. It's about overloading the server. Sure, as you point out, the heavy server traffic is caused by many factors, but as they and Travis and others have pointed out, the scripts are just making things worse, and adding to the decrease in available work throughput.
9) Message boards : Number crunching : Why is it so hard to get work? (Message 23353)
Posted 25 May 2009 by Bill & Patsy
Post:
Thanks Travis and Blurf. It's really good (and a relief!) to hear from you on this.
10) Message boards : Number crunching : Why is it so hard to get work? (Message 23327)
Posted 25 May 2009 by Bill & Patsy
Post:
Contrary to whom ever thinks what, scripters are not, repeat NOT creating a DoS attack.
Why? The forum and in turn the website are still functioning. The users are getting responses back from the update server stating 'no work available' or some other explicable response. If any of these things were non responsive, or errored in result then you could possibly have an argument. So until it does get off the high horse with the false statements and accept the the truth cause it is simply not happening like you say it is.

There's too much emotion in this discussion for people to be expressing opinions as fact, especially when their opinions are incorrect. Let's please be careful to qualify opinions as just that - opinions. The above quote is an example of an incorrect opinion, as I will explain in a moment.

Another incorrect opinion not supported by the facts is:


The lack of WU's created is not caused by those using scripts.

That could well be a revelation to some.

"Read my lips..."

Concerning this latter error, quoting Brian yet again:

What you all have been overloading is the BOINC Feeder <--> BOINC Scheduler daemon interfacing. I don't know why this is so difficult for so many to understand.

These are FACTS folks. Facts which some have been ignoring. It follows directly that if the DoS attack were stopped, yet even more science would be done because more total work would get through. Certainly that would not completely solve the problem. There would still be a shortage. But the scripts are just as certainly part of the cause of that shortage.

Concerning whether there actually is a DoS attack underway, the FACT is that there is a scripter DoS attack going on against MilkyWay. I previously stated a brief set of facts that demonstrate this, and provided a link to the Wikipedia. I quote that posting again here:

The folks using scripts are perpetrating a DoS attack. The intent of the scripters is to force their own way to the head of the line so that the scripters can have it to themselves, thereby making the service unavailable to others. The attack fits the Wikipedia definition: "an attempt to make a computer resource unavailable to its intended users. ...it generally consists of the concerted efforts of a person or persons to prevent an Internet site or service from functioning efficiently...". See the full Wikipedia article Denial-of-service attack. The article establishes that the scripters are perpetrating a DoS attack.

That was but a quick statement of a few facts to establish a prima facia case. The rest was left to the reader. And whether you agreed with that opening statement or not, if you had done your homework and studied the fuller explanation in the Wikipedia article, you would understand that, as I also stated in another posting below, a DoS attack does not have to be 100% successful to qualify as an attack. All it has to do is to prevent the target of the attack from "functioning efficiently" (see above Wikipedia quote). And it's been clearly established that the scripts are interfering with the operation of the MW server and causing it to operate less efficiently. If the server were not already overloaded, then the scripts would be harmless. But under the present circumstances, the scripts are a DoS attack.

Please go read the Wikipedia article (Denial-of-service attack) so that your opinions can be informed opinions. And as you do, please note the statement in the Wikipedia article that "Denial-of-service attacks are considered violations of the IAB's Internet Proper Use Policy. They also commonly constitute violations of the laws of individual nations.".

Thank you.
11) Message boards : Number crunching : Why is it so hard to get work? (Message 23272)
Posted 25 May 2009 by Bill & Patsy
Post:
It's a pity that some have to complain about others doing more science than ever before.

That's a red herring. The reality is that the scripters' DoS attack is interfering with doing the most science possible by overloading the server and reducing the total throughput. Brian explained it below:

What you all have been overloading is the BOINC Feeder <--> BOINC Scheduler daemon interfacing. I don't know why this is so difficult for so many to understand.

If the DoS attack were stopped, yet even more science would be done because more total work would get through.

And yes, it is a DoS attack. It doesn't have to be 100% successful before it qualifies as an attack. Go back and read the Wikipedia article. And having a pure heart and the most sincere intentions doesn't excuse the attack either.

The bottom line is that MilkyWay@home is under a scripters' DoS attack that is reducing the total possible work throughput, and thus reducing the total science that could be done.
12) Message boards : Number crunching : Why is it so hard to get work? (Message 23252)
Posted 25 May 2009 by Bill & Patsy
Post:
The folks using scripts are perpetrating a DoS attack. The intent of the scripters is to force their own way to the head of the line so that the scripters can have it to themselves, thereby making the service unavailable to others. The attack fits the Wikipedia definition: "an attempt to make a computer resource unavailable to its intended users. ...it generally consists of the concerted efforts of a person or persons to prevent an Internet site or service from functioning efficiently...". See the full Wikipedia article Denial-of-service attack. The article establishes that the scripters are perpetrating a DoS attack.
13) Message boards : Number crunching : Why is it so hard to get work? (Message 23219)
Posted 24 May 2009 by Bill & Patsy
Post:
I'm with you Brian and Bill & Patsy - not sure of the grammar when 1 user is/are 2 people ;)

I don't use a script, but I still get WUs from time to time.

To all those who use scripts:
What part of "there isn't enough work being generated to feed all the hosts" don't you understand? Sure, using a script increases your chance of requesting work when there happens to be work, but it does NOT increase the amount of work available, possibly it even reduces it with the extra server load.

Oh well, I'll take whatever I happen to get and other projects can get the rest of my CPU time.

Rod

Hi Rod,

Concerning "our" name, Patsy's machine runs on our account too, but she never posts... Thanks for noticing. ;-)

Concerning the amount of work being generated, it seems to me, after reading so many comments in so many threads, that the server has been set to maintain between 500 and 1000 results ready to send. So it can indeed generate more if it sees more demand. The problem is that the DOS attack from the scripts is reducing the server's ability to distribute the work it has available. If the number and rate of requests were reduced, then more work units would be distributed in response to each request, and the net throughput and work generation would increase.

All this could be answered, and probably fixed, by Travis & Co. with but a few minutes of courteous respect for their user community. But alas, (unless I missed a post somewhere) they haven't put the debate to rest. Don't the users deserve more respect? I know Travis is working hard on the CUDA application, but my suggestion was made a month and a half ago. If they had spared just a couple minutes to respond, then the entire user community could have been spared these weeks and weeks and weeks of frustration and acrimony.

Is this showing respect for the users? (:-/

How about it Travis?
14) Message boards : Number crunching : Why is it so hard to get work? (Message 23213)
Posted 24 May 2009 by Bill & Patsy
Post:
To wit: I suggested a solution


Worth a try... Set it for 15 minutes like at LHC... I'm sure someone will be along soon enough though to complain that their card goes through tasks quicker than that...

I think the only real long-term solution is to get these folks over to their own server so they can compete with themselves instead of with everyone.

Despair is just so relevant...


Brian, yes, your Despair posters are so apropos!
15) Message boards : Number crunching : Why is it so hard to get work? (Message 23191)
Posted 24 May 2009 by Bill & Patsy
Post:
If a table is just barely able to stand the weight of the items sitting on it, would the rational course of action be to add more items to the table, thus increasing the amount of weight the table has on it?

If you were driving in the snow and you went off the side of the road and got stuck, if you didn't have a shovel, would the rational course of action be to press the gas pedal all the way to the floor to try to free yourself?

IMO, and I know I'm in the minority on this one, these scripts are at least partly to blame for everyone's struggles in getting work...

Many of you seem to have this belief:



You are completely right Brian. Sadly, there are several users who aren't the least embarrassed to keep pushing to the front of the line, even though it messes things up for everyone, including themselves. But Travis & Co. apparently don't care either. To wit: I suggested a solution, the same one used successfully by LHC@Home (see this thread: Travis: Please set a minimum update interval). But Travis & Co. ignored it, even though it would have taken them only a couple minutes to implement. Further, they didn't even answer the few simple questions people raised in the thread about what was actually happening in the server. So all we got was a lot of speculation, and lots of flames from the folks I suspect are the real villains who are using the scripts and screwing up the server.

Travis & Co. could still fix this. Easily.
16) Message boards : Number crunching : Is milkyway@home dead? (Message 19211)
Posted 17 Apr 2009 by Bill & Patsy
Post:
--<snip>--
There is a problem. The server status indicates there are 813 units ready, but my boinc gets: No work available.

Dont forget that the server_status page is a snapshot approx 10 minutes ago. So those WUs could have been snapped up.
--<snip>--

Sorry, but that kind of advice appears to me to be misleading, and there's already too much confusion and frustration as it is. So, until Travis & Co. kindly tell us what's really happening on the server, please avoid statements of "fact" unless it is fact.

To wit: I have never seen the ready units level below 400, and I've checked many, many, many, many times. If it ever fell to zero, then 10 minutes later (or whenever the refresh happened), it would have shown as zero (or very, very low). It never has for me. So I don't believe this idea that the refresh delay hides an empty supply.

Now, if work is being prepared in batches rather than continuously, and if the refresh happens at the same time a new batch is prepared, then your speculation has merit.

Does anyone know?
17) Message boards : Number crunching : Travis: Please set a minimum update interval (Message 17688)
Posted 6 Apr 2009 by Bill & Patsy
Post:
--<snip>--
Either way, setting update limits will not increase the amount of available work.
--<snip>--

You're not paying attention.

The problem is not with work unit creation. See (once again) Server Status. The work is there. Even if the status page has a problem, as Holger suggested, I don't see it at zero. It seems to hover between 600-1000. So the work is available.

The problem is with work distribution. It's just not getting distributed efficiently.

So what's wrong with giving this proposal a try? Those of you who keep saying it won't work, without really knowing, are like a bunch of academics sitting around arguing about whether it's raining instead of doing a simple experiment by going outside to see.

Hammering and spamming a server is not a good thing. BOINC has recognized this, and has provided an option to prevent it via a minimum interval. There is work: Server Status. Let's try giving the server some headroom to get the work distributed. If I'm right, the graphs will come up. If I'm wrong, Travis can turn it off.

At least we'll know if it's raining. ;-)

Also, I agree with Patrick: until many other projects also support GPU, the GPU users will continue to swarm to MW and any "fix" will not help for long.

But help is help. And a minimum update interval will help. It deserves a test.
18) Message boards : Number crunching : Travis: Please set a minimum update interval (Message 17603)
Posted 5 Apr 2009 by Bill & Patsy
Post:
At this point its kind of useless. As Travis will be splitting the project.
--<snip>--

How long will that take? My suggestion should take about a minute to implement -- it's just a server setting. Splitting the project looks like it's going to take a little longer.


By the looks of your rac I see that you have maybe one or two machines on this project. Well to do as you ask would cause a drop in total project production to maybe 25 % of what it is now. so you would ask Travis to dump 75% of his data being done daily to make a few happy. As you and many others may be aware that this is a work in progress project. It may not make everyone happy but the end result of this project will be more work done in less time. I also understand that it is making some upset that the work is not there all of the time but lets just face it. Those like myself have many thousands of dollars in computer systems, and this is one of our main hobbies. My daily output production is in excess of 500k Now you would have me stop my machines so that those who have one or two machines may be happy that they got to get up to 10k per day. NOT!!

As to when the project will split? only Travis will know. But until that happens Be happy.......

PD-DD,




Good Grief, Dr. Dan!! A little touchy are we? It's not helpful for you to misrepresent the proposal. Perhaps if you let go of your angst and choose instead to understand the facts, you'll realize that there will not be a drop in total project production but just the opposite. Please go back and read what I've previously posted. There is plenty of work out there for everyone, including you. (Again, see Server Status, as I indicated earlier below.) The problem appears to be that the spammers are choking the server so the server doesn't get a chance to distribute all the work that's already there and available. If the server causes the spammers to back off just a little and stop hammering it so badly, more work will flow. Even to you!! Because each time you ask for work, it will be available and you'll get what you need, unlike now.

You should be supporting this proposal. It's in your best interest too. It will improve work flow to everyone. And until you understand it, please don't make false statements that might get other folks upset.

Finally, suppose I'm wrong. Are you implying that Travis is a fool? Or stupid? That he'd leave it on as the project tanked? Good grief! (Again.) If it doesn't work, he'll shut it off, and no real harm will have been done. It's called an experiment. Scientists do these sorts of things, Dr. Dan.

Thanks for your understanding.
19) Message boards : Number crunching : Travis: Please set a minimum update interval (Message 17595)
Posted 5 Apr 2009 by Bill & Patsy
Post:
At this point its kind of useless. As Travis will be splitting the project.
--<snip>--

How long will that take? My suggestion should take about a minute to implement -- it's just a server setting. Splitting the project looks like it's going to take a little longer.
20) Message boards : Number crunching : Travis: Please set a minimum update interval (Message 17566)
Posted 4 Apr 2009 by Bill & Patsy
Post:
Interesting concept 'having *everyone* back off to some minimum interval' sounds like a view toward credit crunching altruism which, if applied to real social problems would eliminate poverty and war. Probably would require some modification of the human genome though....

--<snip>--
Some have suggested that the "no work available" update problem is that the available work cannot load into the scheduler or upload/download server, or whatever, fast enough because the server is getting hammered so hard by all these requests. So if everyone backed off to some minimum interval, then we all could get work, maybe even on the first request, because the server would have time to actually serve us.

If this works, then everyone will be served, and those of you who are pushing to the front of the line will be fed plenty too without having to be so pushy. Those scripts may help some individuals, but they're hurting everyone else. A proper minimum update interval could fix this.

It's sure worth a try.

Yup. It's the classic "Problem of the Greens" (e.g., not very many people will pay their taxes voluntarily unless the law compels them to). That's why it has to come from Travis - from the server side (a server setting that's enforced by the server, as done at LHC and abc).


Next 20

©2021 Astroinformatics Group