I don't know how many GPUs are already in use on this project, but with more likely to be used soon I would think it a good idea to increase the size of each wu, so there will not need to be so many requests.

I'd rather have a real fix for the problem, because if we do this the same problem will just show up again when we get more users and starting seeing the same amount of workunit requests...

Larger work units would be a real fix, and would give you more time to sort out the problem with how slowly work is being released at times.

---

I don't know how many GPUs are already in use on this project, but with more likely to be used soon I would think it a good idea to increase the size of each wu, so there will not need to be so many requests.

I'd rather have a real fix for the problem, because if we do this the same problem will just show up again when we get more users and starting seeing the same amount of workunit requests...

Larger work units would be a real fix, and would give you more time to sort out the problem with how slowly work is being released at times.

I brought this up a couple weeks ago and Travis said they contain enough info and the 'group' doesn't want to increase the size any more.

---

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

I don't know how many GPUs are already in use on this project, but with more likely to be used soon I would think it a good idea to increase the size of each wu, so there will not need to be so many requests.

I'd rather have a real fix for the problem, because if we do this the same problem will just show up again when we get more users and starting seeing the same amount of workunit requests...

Larger work units would be a real fix, and would give you more time to sort out the problem with how slowly work is being released at times.

I brought this up a couple weeks ago and Travis said they contain enough info and the 'group' doesn't want to increase the size any more.

LOL, I'd love to know what majority group thinks everything is fine as it is :)

---

I brought this up a couple weeks ago and Travis said they contain enough info and the 'group' doesn't want to increase the size any more.

LOL, I'd love to know what majority group thinks everything is fine as it is :)

Whoever he is supposed to see about the project. Probably the same people who don't think a second server is needed. :P

---

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

I looked randomly at 10 of the top 100 computer’s RAC – they are all ATI equipped.

I expect the top crunchers amassed most of their credits before the ATIs were available for optimized crunching. ATI GPU crunching is relatively quite recent and I expect people want a stable period of crunching with the ATIs before saying how they are doing with them.

---

Wait a second...

Resetting the project as a workaround to get more work might be counter productive. The reason is that even if you already have the third party apps to install afterwards, your host is going to have to re-download all the input files it needs that got dumped from the reset. If running stock, it will have to download the app again too.

This is probably not going to do much to help the overall situation. ;-)

Alinator

No, Resetting the Project won't get rid of any Optimized App's, Third Party App's I don't know about but the Optimized ones don't get taken out when Resetting. Yes you'll have to re-download the input files & if you have Dial-Up it could take some time or pose a problem.

I do it all the time but I have Cable so it's no big deal for me to re-download the input files, it only takes a few seconds for me to do that. It works for me but if somebody has a problem with it then don't do it, more work for me then ... :)

Agreed, not all CC's will dump the whole project directory on a reset. However, all will dump the stock app on one.

However, that wasn't the real point. The new GPU apps are bandwidth and work sponges from the Projects POV.

Therefore, 'casual' resetting forces those hosts to pull all the input files and a whole new set of work from empty, with the attendant DB and and bandwidth load that goes along with that. Given that the project is having trouble keeping up as it is, anything that increase that even more only makes things worse for the big picture. Also, there is no guarantee that the scheduler queue hasn't been sucked dry just as the host gets reset, so the whole process would have been done for no net gain in that case.

Alinator

I know have work on all computers and including the GPU where I was getting practically nothing.

I know have work on all computers and including the GPU where I was getting practically nothing.

Server-side, it looks like the change helped work availability quite a bit.

---

I know have work on all computers and including the GPU where I was getting practically nothing.

Server-side, it looks like the change helped work availability quite a bit.

LOL...

Well, we had our three steps backwards over the last 36 hours or so.

So I guess that would be about 2 1/2 forward now? ;-)

Alinator

I know have work on all computers and including the GPU where I was getting practically nothing.

Server-side, it looks like the change helped work availability quite a bit.

The only problem- and it's a big one- is when you have 'got 0 new tasks' multiple times in a row, which does still happen, and run dry and the reconnect time goes to 2 or 3 hours and you have nothing to crunch until then... any way to change/fix(?) that?

I know have work on all computers and including the GPU where I was getting practically nothing.

Server-side, it looks like the change helped work availability quite a bit.

The only problem- and it's a big one- is when you have 'got 0 new tasks' multiple times in a row, which does still happen, and run dry and the reconnect time goes to 2 or 3 hours and you have nothing to crunch until then... any way to change/fix(?) that?

It depends on what mean by 'fix'.

If you are talking about MW being able to feed work to the scheduler faster, then no, not until Monday at the earliest.

If you're talking about not running dry, then you have two choices:

1.) Sit at the console all the time and pound on the update button when you are out.

2.) Run a backup project and just ride out these difficulties until a satisfactory backend fix can be implemented.

Alinator

The only problem- and it's a big one- is when you have 'got 0 new tasks' multiple times in a row, which does still happen, and run dry and the reconnect time goes to 2 or 3 hours and you have nothing to crunch until then... any way to change/fix(?) that?

It depends on what mean by 'fix'.

If you are talking about MW being able to feed work to the scheduler faster, then no, not until Monday at the earliest.

If you're talking about not running dry, then you have two choices:

1.) Sit at the console all the time and pound on the update button when you are out.

2.) Run a backup project and just ride out these difficulties until a satisfactory backend fix can be implemented.

Alinator

I think he was talking about the 3 hour delay.

---

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

So far, I've seen *none* of the 0 responses

I spoke too soon. Quite a few 0 responses hidden in the logs, and running dry on one occasion. But still a significant improvement over both the previous per-core quotas tried, as far as my crunchers are concerned.

---

So far, I've seen *none* of the 0 responses

I spoke too soon. Quite a few 0 responses hidden in the logs, and running dry on one occasion. But still a significant improvement over both the previous per-core quotas tried, as far as my crunchers are concerned.

Should be even better now that the workunits should take around twice as long to crunch.

---

Should be even better now that the workunits should take around twice as long to crunch.

Huh. Making us work twice as slow eh? :p

---

The only problem- and it's a big one- is when you have 'got 0 new tasks' multiple times in a row, which does still happen, and run dry and the reconnect time goes to 2 or 3 hours and you have nothing to crunch until then... any way to change/fix(?) that?

It depends on what mean by 'fix'.

If you are talking about MW being able to feed work to the scheduler faster, then no, not until Monday at the earliest.

If you're talking about not running dry, then you have two choices:

1.) Sit at the console all the time and pound on the update button when you are out.

2.) Run a backup project and just ride out these difficulties until a satisfactory backend fix can be implemented.

Alinator

I think he was talking about the 3 hour delay.

'If you are talking about MW being able to feed work to the scheduler faster...'
I'm not.

'I think he was talking about the 3 hour delay.'
I was.

Good to see that the idea of increasing the size of a work unit was eventually taken on board. Making them smaller always seemed crazy when they are mostly completed so fast :)

---

Should be even better now that the workunits should take around twice as long to crunch.

Huh. Making us work twice as slow eh? :p

Ooh 2 seconds then.

---

me@rescam.org

Should be even better now that the workunits should take around twice as long to crunch.

Huh. Making us work twice as slow eh? :p

Ooh 2 seconds then.

Hey now, some of the GPU apps are taking a whole 3 seconds.

---

Should be even better now that the workunits should take around twice as long to crunch.

Huh. Making us work twice as slow eh? :p

Ooh 2 seconds then.

Hey now, some of the GPU apps are taking a whole 3 seconds.

Need a faster app now.

---

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