My main cruncher is fitted with two different graphics cards a GTX460 and a GT430. There is a significant speed difference (about a factor of 7) between these two graphics cards. I am getting a few computation errors due to tasks being processed by the GT430 exceeding the time allowed. I assume the calculation of the time allowed is dominated by the performance of the GTX460. Most of the time GT430 tasks complete without difficulty, the problem seems to be limitted to those with a particularly difficuly angle range which take longer to crunch and is resulting in around 2 errors a day.

Is this a case where flops might be useful? I have never experimented with the flops command so any advice would be helpful. Is it directly proportional to processing power? i.e. if I work out my current flops value and halve it will BOINC think my graphics cards are now half as powerful and double the allotted time for each WU? This would be enough to stop the computation errors.

---

I am wondering if those tasks are falling back to the CPU for some reason as that is a very long time for a Fermi class GPU to try crunching.

Does GPUZ show that the cards are running around 100% all the time?

---

I am wondering if those tasks are falling back to the CPU for some reason as that is a very long time for a Fermi class GPU to try crunching.

Does GPUZ show that the cards are running around 100% all the time?

Both cards are running 100% of the time and are >99% used. I run 2WU at a time on both cards as the system is optimized for the GTX460. This may explain why the GT430 tasks take so long.

---

I had a go at running two at a time on my GT430 and it was a big backwards step
Tasks took nearly three times as long to complete,

...
Is this a case where flops might be useful? I have never experimented with the flops command so any advice would be helpful. Is it directly proportional to processing power? i.e. if I work out my current flops value and halve it will BOINC think my graphics cards are now half as powerful and double the allotted time for each WU? This would be enough to stop the computation errors.

No, flops would not help because they can't be set differently for the different cards. If you halved the flops, it would only help for work already in cache. The servers would compensate and halve the rsc_fpops_est values for new work so you'd be right back where you started.

Boosting the rsc_fpops_bound values using the rescheduler is probably the simplest cure.

                                                                   Joe

I am wondering if those tasks are falling back to the CPU for some reason as that is a very long time for a Fermi class GPU to try crunching.

Does GPUZ show that the cards are running around 100% all the time?

Both cards are running 100% of the time and are >99% used. I run 2WU at a time on both cards as the system is optimized for the GTX460. This may explain why the GT430 tasks take so long.

The GT430 is a really cheap GPU, low power, low cost... low performance.
Anyway I have 2 of them both running 2 Wus each and it works for me because the crunching times of running 2 are really less than twice the time of running just 1.
I guess that your best option (without babysitting) is to not mix the 430 with the 460, Ive seen that you have a 9500 in another system, pairing the 430 with that could work better as the crunching times will not be so different (at least not by a factor of 7)

---

I had a go at running two at a time on my GT430 and it was a big backwards step
Tasks took nearly three times as long to complete,

Unfortunately BOINC does not let you set different numbers of simultaneous tasks for different graphics cards. I want to run 2 at a time on the GTX460 to get the most out of that card which dominates the system so I have to run 2 at a time on the GT430.

---

I am wondering if those tasks are falling back to the CPU for some reason as that is a very long time for a Fermi class GPU to try crunching.

Does GPUZ show that the cards are running around 100% all the time?

Both cards are running 100% of the time and are >99% used. I run 2WU at a time on both cards as the system is optimized for the GTX460. This may explain why the GT430 tasks take so long.

The GT430 is a really cheap GPU, low power, low cost... low performance.
Anyway I have 2 of them both running 2 Wus each and it works for me because the crunching times of running 2 are really less than twice the time of running just 1.
I guess that your best option (without babysitting) is to not mix the 430 with the 460, Ive seen that you have a 9500 in another system, pairing the 430 with that could work better as the crunching times will not be so different (at least not by a factor of 7)

Nice idea but the PC with the 9500 in it only has one PCIe slot:(

---

I am wondering if those tasks are falling back to the CPU for some reason as that is a very long time for a Fermi class GPU to try crunching.

Does GPUZ show that the cards are running around 100% all the time?

Both cards are running 100% of the time and are >99% used. I run 2WU at a time on both cards as the system is optimized for the GTX460. This may explain why the GT430 tasks take so long.

The GT430 is a really cheap GPU, low power, low cost... low performance.
Anyway I have 2 of them both running 2 Wus each and it works for me because the crunching times of running 2 are really less than twice the time of running just 1.
I guess that your best option (without babysitting) is to not mix the 430 with the 460, Ive seen that you have a 9500 in another system, pairing the 430 with that could work better as the crunching times will not be so different (at least not by a factor of 7)

Nice idea but the PC with the 9500 in it only has one PCIe slot:(

Put the 460 in that machine and the 9500 in this one.

---

Nice idea but the PC with the 9500 in it only has one PCIe slot:(

Put the 460 in that machine and the 9500 in this one.

Wish I could but the dual GPU PC is my office machine whilst the single GPU PC is at home. Cannot take GPUs from work:(

---

I guess that your best option (without babysitting) is to not mix the 430 with the 460, Ive seen that you have a 9500 in another system, pairing the 430 with that could work better as the crunching times will not be so different (at least not by a factor of 7)

Nice idea but the PC with the 9500 in it only has one PCIe slot:(

Another option will be to swap GPUs between your hosts, the 460 in the 1 PCI host and the others on another... (It might not the best option, as I guess you want the best GPU on the faster host for other uses besides crunching... but...)

EDIT: Im late ... LOL

---

I ran mixed speed GPUs on http://setiathome.berkeley.edu/show_host_detail.php?hostid=6379672 without getting this issue for 3 months but over the past few weeks it is happening more and more. I have just written a small C program that updates all the <rsc_fpops_bound> values in the client_state.xml to be 25 rather than 10 times the <rsc_fpops_est> values which should resolve this, I just need to stop BOINC and run it every few days. It also resets the DCF to 1.0.

I think you can do similar with Fred’s rescheduler, but have never used it.

The real problem is that BOINC thinks all the GPUs in a system must be the same speed and unless this is fixed running mixed speed GPUs will have issues. The main one for me now is that it's impossible to get a stable DCF. I just hope set@home starts using the <dont_use_dcf/> facility.

I ran mixed speed GPUs on http://setiathome.berkeley.edu/show_host_detail.php?hostid=6379672 without getting this issue for 3 months but over the past few weeks it is happening far more. I have just written a small C program that updates all the <rsc_fpops_bound> values in the client_state.xml to be 25 rather than 10 times the <rsc_fpops_est> values which should resolve this, I just need to stop BOINC and run it every few days. It also resets the DCF to 1.0.

I think you can do similar with Fred’s rescheduler, but have never used it.

The real problem is that BOINC thinks all the GPUs in a system must be the same speed and unless this is fixed running mixed speed GPUs will have issues. The main one is that it's impossible to get a stable DCF. I just hope set@home starts using the <dont_use_dcf/> facility.

This sort of thing is a pet hate of mine. BOINC does not work at the correct granularity. Each processing resource should have its own set of values. I think the current situation is as a result of the knee jerk reaction when CUDA processing first came about (ie, make it happen). In the meantime, nobody has gone back and re-coded to do resource management properly. Frustrating, but I don't think it will change very soon - if at all.

I guess the real problem is the legacy apps some people may be running, such that if the structure of the XML files was changed significantly - the old apps still in use would break. This all seems to stem from a fundamental design decision years ago (pre GPU), in the sense that BOINC can't handle the current possibility that newer machines may have multiple processing resources, each with their own characteristics.

IMHO, BOINC needs a complete re-write - but that would be a huge task - and that's even less likely to happen!

---

No, flops would not help because they can't be set differently for the different cards. If you halved the flops, it would only help for work already in cache. The servers would compensate and halve the rsc_fpops_est values for new work so you'd be right back where you started.

Thank you for this Joe. I keep getting told I need to set the FLOPS and when I do so it works for a while and then the ERR_RSC_LIMIT_EXCEEDED errors start again. I suspected this was happening, but was unsure.

This sort of thing is a pet hate of mine.

+1 (one who if very tempted to at least fix BOINC to allow for different GPU speeds).

I ran mixed speed GPUs on http://setiathome.berkeley.edu/show_host_detail.php?hostid=6379672 without getting this issue for 3 months but over the past few weeks it is happening more and more. I have just written a small C program that updates all the <rsc_fpops_bound> values in the client_state.xml to be 25 rather than 10 times the <rsc_fpops_est> values which should resolve this, I just need to stop BOINC and run it every few days. It also resets the DCF to 1.0.

I think you can do similar with Fred’s rescheduler, but have never used it.

The real problem is that BOINC thinks all the GPUs in a system must be the same speed and unless this is fixed running mixed speed GPUs will have issues. The main one is that it's impossible to get a stable DCF. I just hope set@home starts using the <dont_use_dcf/> facility.

I agree that the problem seems to have got worse recently (since the limits were raised). I bought the GT430 in Feburary and had no problems until about a week ago. Then it has been about 2WU a day that fail to complete.

I have now removed the GT430 card until someone can come up with a solution or I better understand what is going on. I thought I understood flops but apparently not and these there parameters are beyond me.

---

This sort of thing is a pet hate of mine.

+1 (one who if very tempted to at least fix BOINC to allow for differen GPU speeds).

+2

---

No, flops would not help because they can't be set differently for the different cards. If you halved the flops, it would only help for work already in cache. The servers would compensate and halve the rsc_fpops_est values for new work so you'd be right back where you started.

Boosting the rsc_fpops_bound values using the rescheduler is probably the simplest cure.

                                                                   Joe

I thought flops override the APR mechanism?
what's the use of adding flops then at all, if the server will compensate?

---

I'm not the Pope. I don't speak Ex Cathedra!

No, flops would not help because they can't be set differently for the different cards. If you halved the flops, it would only help for work already in cache. The servers would compensate and halve the rsc_fpops_est values for new work so you'd be right back where you started.

Boosting the rsc_fpops_bound values using the rescheduler is probably the simplest cure.

                                                                   Joe

I thought flops override the APR mechanism?
what's the use of adding flops then at all, if the server will compensate?

Good question. I think I started the whole cottage industry of adding <flops> entries with this beta post - but that was back in March 2009, just a couple of months after CUDA (no ATI at that stage) crunching got properly under way. At that point, just after the launch of the first BOINC version which attempted to support CUDA properly, there was no way to stabilise DCF except by manually inserting flops estimates.

About 15 months after that initial suggestion, CreditNew arrived here, and with it the automatic APR mechanism - which replaces both DCF and <flops>. My advice then was, and remains, not to use any manual <flops> entries: though if anybody has been using them as a temporary measure while APR has been hors de combat, they should probably think carefully before removing them.

No, flops would not help because they can't be set differently for the different cards. If you halved the flops, it would only help for work already in cache. The servers would compensate and halve the rsc_fpops_est values for new work so you'd be right back where you started.

Boosting the rsc_fpops_bound values using the rescheduler is probably the simplest cure.

                                                                   Joe

I thought flops override the APR mechanism?
what's the use of adding flops then at all, if the server will compensate?

No, for anonymous platform the servers scale rsc_fpops_est and rsc_fpops_bound by the ratio of flops/(APR*1e09). Adding <flops> in app_info.xml keeps the client from sending a hugely wrong guesstimate of what they should be. Particularly for new applications it provides a way to keep DCF stable and estimates of runtime reasonable.

For stock, once APR is established, APR*1e09 is sent as the flops for each app_version. Adding <flops> in app_info.xml is the available method to simulate that on anonymous platform, otherwise the client is sending flops based on the Whetstone CPU benchmark.

                                                                  Joe