As I pointed out in this message and to Travis...

To stop the scriptors hitting the project so hard, you could increase the minimum time between host contacts at the server end. LHC@home increased theirs to just over 15 minutes....maybe you could try 2 minutes and see what happens. I believe it is a simple server side setting.

That's what Bill was suggesting, and got shot down for it... Personally, I don't think 2 minutes is long enough. Needs to be at least 10. I'm sure though that 10 will cause a huge amount of complaining about how that means that someone might have 3-5 minutes of not being able to get anything, although I'm not sure how that's different from the current situation, but then again, I view this from the perspective of solving a problem, not from the eyes of a competitor in a competition.

And something I posted got shot down as well...

If you limit the # of WUs per core, there should be plenty for all. 5k per CPU is a bit much, even if you run only CPUs...

I vote no to the limiting of wu do I hear a second it motion?

---

As I pointed out in this message and to Travis...

To stop the scriptors hitting the project so hard, you could increase the minimum time between host contacts at the server end. LHC@home increased theirs to just over 15 minutes....maybe you could try 2 minutes and see what happens. I believe it is a simple server side setting.

That's what Bill was suggesting, and got shot down for it... Personally, I don't think 2 minutes is long enough. Needs to be at least 10. I'm sure though that 10 will cause a huge amount of complaining about how that means that someone might have 3-5 minutes of not being able to get anything, although I'm not sure how that's different from the current situation, but then again, I view this from the perspective of solving a problem, not from the eyes of a competitor in a competition.

And something I posted got shot down as well...

If you limit the # of WUs per core, there should be plenty for all. 5k per CPU is a bit much, even if you run only CPUs...

I guess it all boils down to whether or not the other project is anywhere near being ready for use. If it is going to be another 1-3 months, then I'd suggest the project implement some kind of throttle of their own rather than letting users throttle it for them. It simply cannot be good to be running near or at capacity for such an extended period of time.

Note to potentially offended GPU folk: I include myself as a "user". We all end up adding to the load in various amounts.

Once the GPU traffic is over on the MilkyWay_GPU project *including* ATI-GPU support since until then the only home for ATI_GPU processing is right here, then setting a 5 or 10 minute time out (Spinhenge does 15 minutes as well) shouldn't cause a problem since a) the likelyhood of getting work on a single pass should go up and b) even the fast current computers take about 10 minutes per core to complete work units. Heck, once the load here goes down, Travis might be able to push the cache back up from 6 work units per CPU to something more reasonable (say 15 to 25) which would also reduce the need for scripts. For Spinhenge every 15 minutes you can download up to 10 workunits, those work units each take about 30 minutes on my AMD 940 workstation. Spinhenge has a max cache of 75 workunits per PC (not per core), and plenty of work there.

As long as there is support here for the ATI_GPU application -- then even a 2 minute time out might be seen as a real constraint for GPU crunchers. As Travis has noted, once the GPU project is fully running (including ATI support), the plan is to force a GPU/CPU split of the project. Once that happens, the load on the CPU side should be significantly less, the incentive to run scripts should be significantly less, and setting up a 5 to 10 minute time out (to counter those who persist in running scripts on the CPU side) should be just fine.

So for all the angst of the past month or two regarding scripts and work availability, it would seem we are much closer to the end of the work availability problem (ie say 2 to 4 weeks) than the initial onset of the outage issue (6 months ago).

So it seems to me that a lot of the back and forth fire/counterfire traffic right now only makes sense for those who thirst for Monty Python argument exercise.

That's what Bill was suggesting, and got shot down for it... Personally, I don't think 2 minutes is long enough. Needs to be at least 10. I'm sure though that 10 will cause a huge amount of complaining about how that means that someone might have 3-5 minutes of not being able to get anything, although I'm not sure how that's different from the current situation, but then again, I view this from the perspective of solving a problem, not from the eyes of a competitor in a competition.

---

only makes sense for those who thirst for Monty Python argument exercise.

No it doesn't... ;)

only makes sense for those who thirst for Monty Python argument exercise.

No it doesn't... ;)

Yes it does...

---

Calm Chaos Forum...Join Calm Chaos Now

"Is this the 15 minute argument or the full half hour?"
Going by the length of this thread...

---

Cheers,

PeterV

.

I vote no to the limiting of wu do I hear a second it motion?

Seconded.

Hold on. The sky's the limit. Let me think about it...

---

Once the GPU traffic is over on the MilkyWay_GPU project *including* ATI-GPU support since until then the only home for ATI_GPU processing is right here, then setting a 5 or 10 minute time out (Spinhenge does 15 minutes as well) shouldn't cause a problem since a) the likelyhood of getting work on a single pass should go up and b) even the fast current computers take about 10 minutes per core to complete work units. Heck, once the load here goes down, Travis might be able to push the cache back up from 6 work units per CPU to something more reasonable (say 15 to 25) which would also reduce the need for scripts. For Spinhenge every 15 minutes you can download up to 10 workunits, those work units each take about 30 minutes on my AMD 940 workstation. Spinhenge has a max cache of 75 workunits per PC (not per core), and plenty of work there.

As long as there is support here for the ATI_GPU application -- then even a 2 minute time out might be seen as a real constraint for GPU crunchers. As Travis has noted, once the GPU project is fully running (including ATI support), the plan is to force a GPU/CPU split of the project. Once that happens, the load on the CPU side should be significantly less, the incentive to run scripts should be significantly less, and setting up a 5 to 10 minute time out (to counter those who persist in running scripts on the CPU side) should be just fine.

So for all the angst of the past month or two regarding scripts and work availability, it would seem we are much closer to the end of the work availability problem (ie say 2 to 4 weeks) than the initial onset of the outage issue (6 months ago).

So it seems to me that a lot of the back and forth fire/counterfire traffic right now only makes sense for those who thirst for Monty Python argument exercise.

Wait a second...

My impression has been that they aren't going to allow GPU's here, for the simple reason of what would be the point of having to manage two separate projects if the net result is the server here on CPU continues to get sacked by the ATi's running on the anonymous platform?

IIRC, the intention has always been to release the source code for the GPU apps once they are in a state to let the guys like CP fold, spindle, and de-mutilate them, so there's no reason they can't run on the anonymous platform on GPU where they belong until BOINC has official ATi support or OpenCL (if that turns out to be viable for HPC, which is still an open question at this point).

Alinator

the ATI's will see no credit difference between the CPU and GPU credit scales.
That has already been pointed out many times. That should discourage GPU guys from running CPU units.

the whole grocery taking wal-mart analogy is well... idiotic as I look at it.
That is all I am going to say about it cause it is pointless to argue with someone that is dead set in their mind that they are right and everyone else is wrong.

---

That is all I am going to say about it cause it is pointless to argue with someone that is dead set in their mind that they are right and everyone else is wrong.

---

me@rescam.org

I agree, but in terms of sequence and timing, my *guess* is that the 'released' CUDA GPU application will see daylight in perhaps two weeks. Then the optimizers will work on an optimized ATI_GPU version for MilkyWay_GPU (not sure how long that will take might be fast, might be weeks, I just don't know). Until that ATI_GPU application is available to the ATI_GPU public running over here, I would *guess* that the existing GPU work being done over here will continue. Then some time after the release of the optimized ATI_GPU via a 3rd party download location, there will be changes done over here at the server parameter level which will preclude the use of the existing ATI-GPU anonymous application over here (not sure of what those changes would be, but some fairly straightforward approaches have been discussed over here already).

The thing is, to immediately make those 'exclusion' changes upon the release of the project generated CUDA application for the GPU project, would leave a bunch of ATI_GPU folks homeless during an intervening period of days to weeks. I don't think that is the sequence Travis has in mind (could be wrong though).

Wait a second...

My impression has been that they aren't going to allow GPU's here, for the simple reason of what would be the point of having to manage two separate projects if the net result is the server here on CPU continues to get sacked by the ATi's running on the anonymous platform?

IIRC, the intention has always been to release the source code for the GPU apps once they are in a state to let the guys like CP fold, spindle, and de-mutilate them, so there's no reason they can't run on the anonymous platform on GPU where they belong until BOINC has official ATi support or OpenCL (if that turns out to be viable for HPC, which is still an open question at this point).

Alinator

---

the whole grocery taking wal-mart analogy is well... idiotic as I look at it.
That is all I am going to say about it cause it is pointless to argue with someone that is dead set in their mind that they are right and everyone else is wrong.

On the contrary, you have not produced any kind of logical argument that there is a legitimate reason that scripts are not only not a hinderance to the project, that they are necessary and vital to the health and well-being of the project and all of its' participants.

BTW, I'm used to being called an idiot by fellow participants, but it is refreshing when the project administrator has mentioned that less science is being done now with the scripts running than without...

Try chewing on that for a bit...

Goodnight...

That is all I am going to say about it cause it is pointless to argue with someone that is dead set in their mind that they are right and everyone else is wrong.

I agree, but in terms of sequence and timing, my *guess* is that the 'released' CUDA GPU application will see daylight in perhaps two weeks. Then the optimizers will work on an optimized ATI_GPU version for MilkyWay_GPU (not sure how long that will take might be fast, might be weeks, I just don't know).

Since CP has pretty much stated that they'll work on it, I don't have much doubt in their capabilities. Barring some disaster, it should be 2-4 weeks. At that point, I can sincerely say that I wish all of the GPU folks well with their future endeavors... ;-)

This is what I remember Travis posting....


Quote:

To be honest, before people started using scripts to hammer the server, we were getting around 9-11 workunits a second. Now we're seeing around 6-7 workunits a second.
____________


Doesn't look like less to me...

Wait a second...

My impression has been that they aren't going to allow GPU's here, for the simple reason of what would be the point of having to manage two separate projects if the net result is the server here on CPU continues to get sacked by the ATi's running on the anonymous platform?

Haven't you heard, it's a battle of words...the poster bearer cried...


Ah, and how fitting the last few words...

...for want of a price of tea and a slice, the old man died...

This is what I remember Travis posting....


Quote:

To be honest, before people started using scripts to hammer the server, we were getting around 9-11 workunits a second. Now we're seeing around 6-7 workunits a second.
____________


Doesn't look like less to me...

Uhhh... 6-7 a second is not LESS than 9-11 a second, in what reality? The only thing I am not sure of in regards to that statement is whether he was talking about outbound or inbound. In either case, it is less...

IF 9-11 inbound before AND 6-7 inbound after, then the amount of science being returned to the project is LESS after than before.

IF 9-11 outbound before AND 6-7 outbound after, then the amount of science being sent out from the project to participants is LESS after than before.

The ONLY way for there NOT to be LESS is if the meaning was really:

IF it took 9-11 seconds before each task was sent to a participant before, but 6-7 seconds before tasks were sent out after.

That is the only way in which a lower number equates to a faster turnaround...for what was said to mean that there was a smaller delay in sending out tasks after the scripts were in more general use than before. That is a considerably different meaning from what most people would translate what was said, so while it is possible that was the meaning, it is highly unlikely. Perhaps you are being thrown off by the use of the three words "to be honest", and you are taking them to mean that there is disagreement with the idea that the number is less...?

OK -- that is about the timeframe I am guessing as well. The one clarification is that until the ATI_GPU applicaton is available over there, I expect that that GPU folks will be doing work on this side.


[/quote]

Since CP has pretty much stated that they'll work on it, I don't have much doubt in their capabilities. Barring some disaster, it should be 2-4 weeks. At that point, I can sincerely say that I wish all of the GPU folks well with their future endeavors... ;-)[/quote]

Oh, I take it that until that point, you wouldn't be sincere in wishing well to GPU folks <g>.

---

IMO, activities in this thread are hammering the servers no less than scripts do. :D

---

Oh may god.:( Close the thread please!