LHC uses a minimum 15 minute interval between client updates. Attempted updates before the interval completes result in no work and the clock is reset for another full interval instead. Such server-side minimum update intervals prevent spamming and hammering the server, which has become a sport at Milkyway and a growing problem for everyone. If you enable this feature, it should stop this nonsense and assure work availability for everyone.

Thanks.

---

--Bill

No problems with me. It takes about 12 minutes for me to complete the maximum number of wu's (6/core) that are allocated. I'd love to be able to get another 24 tasks 3 minutes after completing them versus the approx 20min it takes now!

I don't feel that it would be a good idea.

I have a great idea lets just all stop complaining and crunch what you get and help out the project.

---

It's a great idea

i get sometimes only one or two WUs, i do them in 30 seconds, so this or less has to be the min update interval.

I'll set that in my update script at once - Bill & Patsy, thanks for the suggestion

Or not?

Perhaps it would be better to reduce the deadline from 3 days to 10 minutes, this would make sure those who can do will be supplied with work and the project would not be thwarted by the slow crunchers.

Travis, please!

just kidding of course, but some should really think about what they say before they say

Thanks Dan, that's the way :)

Here Here Dr Dan, think its about time those who are whining about the wu situation go GET A LIFE and wait for Travis to sort something out...

---

A 15 min timeout would be stupid IMO, as the maximum cache you can get with a quad lasts only 12 mins with a 150€ 4870.

However, there is something which oculd be done: after a server request BOINC goes into an automatic timeout of 7 s at MW, whereas this time interval is 1 min by default. Well, a GPU is fast, but it's not that fast.. so if one does actually get a full cache, the next server requests are wasted as BOINC doesn't understand this "reached maximum quota per CPU"-message. If this time is increased to 1 min quite some unneccessary server requests would be eleminated.

It wouldn't stop update scripts or manual updates, though. If you went for the solution Bill & Patsy suggested I recommend a minimum time between connects of not more than 1 min. That should keep people from hammering the server in an unresponsible manner and would still give machines with 2 GPUs or an X2 at least a chance to get new work in time.

MrS

---

Scanning for our furry friends since Jan 2002

abc@home use a 2 min delay.

>give machines with 2 GPUs or an X2 at least a chance to get new work in time.
But first there has to be work ready to d/l...

---

Cheers,

PeterV

.

I agree with the idea, although from the responses about crunch times, perhaps 15 min is a bit long.

But the point is, as soon as it becomes pointless to use scripts to hammer the server more often than the min update interval, crunchers will hopefully stop using them, and the server may just be able to cope better.

Just so you know, I have no GPU and I don't use a script. If I don't get work from MW, Boinc gets from other projects.

15 minutes? Is it a joke?

My 4850 overclocked work on a E5300 (dualcore) and 6 Wu per core do 12 wu in cache !

12 wu in cache does mean a maximum of 6 min of work ! What about the other nine ones?
And what about my 3850 on my celeron single core?

Everybody don't have a big quadcore or Core i7

I don't buy graphics cards for fun !

Why doesn't Travis increase the length again? by five or ten for exemple? This won't be disturbing for CPUs

Hello ???

The interval has to be less than one WU can be done by any client!!!

This is far less than a minute!!!

So the interval has to be set smaller than this - easy to understand, i think

So the update interval can NOT be greater than 30 seconds and i don't know if this caps some hardware already.

This idea lacks any sense!

It's a simple me me me i don't get enough, someone got my pacifier idea, nothing else

Hello ???

The interval has to be less than one WU can be done by any client!!!

This is far less than a minute!!!

So the interval has to be set smaller than this - easy to understand, i think

So the update interval can NOT be greater than 30 seconds and i don't know if this caps some hardware already.

This idea lacks any sense!

It's a simple me me me i don't get enough, someone got my pacifier idea, nothing else

How about making the interval - the culminative time of the number of units downloaded by the given host.

In that, each batch of 6 (per core) is taken as a 'whole' and no new units issued until the 'batch' is complete.

---

won't work too i think
1. Implementation: If i request 48 WU (i7 HT) the server has to wait until there are 48 WU ready to send any subsequent requests will be dropped, that will not help against update scripts
2. Implementation: When the Server has 6 WU ready the first client that requests 6(slowest PCs - 1 core) will get them - this way fast CPUs/GPUs will never get work until slower PCs have enough work

The problem is the behaviour of BOINC it is not made for a situation where no work is available. If a request fails BOINC will increase the time to the next request. This penalizes fast machines as they have to request more frequently than slower ones and so their time to the next request increases very fast and its very likely that they run dry for days. That's why especially GPU-users have to use such scripts to get at least the amount that slower PCs get percentaged.

I've two 4850 GPUs that starve at about 50% of their potential - not funny, but that's the situation. And if i don't use a script i will not get anything because of time to next request is always many hours

I think there can nothing be done than to wait that the project will be able to serve more work and on that solution is worked at the moment. Should they stop their work only to implement some disputable things and we have to wait even longer for a real solution?

I have a great idea lets just all stop complaining and crunch what you get and help out the project.

That is the only thing that can be done at the moment, anything else will delay a real solution and that will end in even more complaining and whining.

If you read between the lines of the complainers, all that they say is: stop the others give it to me! - no need for any attention, sadly if one starts all whiners that could restrain themself start to sing from the same hymn sheet. Thats the point when they stop thinking because some base instict takes control: "I probably miss something" - They don't care about the project, they don't care about others, it's just them

I don't buy graphics cards for fun !

No? So you run CAD-applications on your Celeron-based box?

Sorry, but buying new equipment for BOINC only is in my eyes contradicting the idea of using "unused" cycles.

Save your money for something else, the project itself will most likely not finish much faster with your contribution.


Regards, Lothar

This computer is used for an office automation use and for some little games as Fifa 08 so ...

I don't know why I tell you this, I do what I want with my money that's all. A lot of people do same thing and so what? It's our hobby ! Can you Respect this?

ZeuZ stop buying stupid things like a single graphic card ....
take it at least by two

...
I don't buy graphics cards for fun !
...

I don't get it... Can we get money for credits now?

---

mic.

...
I don't buy graphics cards for fun !
...

I don't get it... Can we get money for credits now?

I kept trying for candy but I am still waiting!! :(

---

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

Getting back to the point...

In my initial post, I purposely did not suggest what the interval should be for MilkyWay. Travis will have to work that out based upon performance results and everyone's feedback. I cited LHC as an example, but yes, the LHC 15 min interval is clearly too long for MilkyWay.

As for "no work available", I don't understand why some people keep saying that. Every time I check the server it has plenty of work available. (The Home Page has a hot link "Server Status" where you can check this.)

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.

---

--Bill

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....

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.

---