I stick mine right under the version number.

You will need to add those numbers to all 6 occurrences of the GPU part.

Thank you

I shall stop rescheduling and let the numbers stabilise and then give it a try.

Just before you add the <flops> entries, I suggest you use the rescheduler to protect against -177 errors for maximum elapsed time exceeded on cached tasks. The expert tab has a setting called something like "limit rsc_fpops_bound" which provides that protection when you do a reschedule, even if the other settings mean that no tasks are actually rescheduled. That's as much as I know, I hope someone with practical experience will provide a clearer explanation.

Those cached tasks will have scaled down rsc_fpops_est which is used to calculate estimated time, and rsc_fpops_bound which is used to calculate the time limit. The big increase in flops will make the times much shorter, but DCF will soon increase to fix the estimates. Unfortunately DCF isn't used for the limit.

                                                                  Joe

Good info Joe, I just put <flops> onto my main cruncher, got -17's. Will give this a try. Or is there a way to edit fpops in the app_info?

Regards,

A

You'd have to increase every single rsc_fpops_bound entry by some 3 magnitudes - one per task. Using the rescheduler is by far the less errorprone option.

I stick mine right under the version number.

You will need to add those numbers to all 6 occurrences of the GPU part.

Thank you

I shall stop rescheduling and let the numbers stabilise and then give it a try.

Seen running with flops for a couple of days, no problems, its all running good.

---

Kevin

I stick mine right under the version number.

You will need to add those numbers to all 6 occurrences of the GPU part.

Thank you

I shall stop rescheduling and let the numbers stabilise and then give it a try.

Just before you add the <flops> entries, I suggest you use the rescheduler to protect against -177 errors for maximum elapsed time exceeded on cached tasks. The expert tab has a setting called something like "limit rsc_fpops_bound" which provides that protection when you do a reschedule, even if the other settings mean that no tasks are actually rescheduled. That's as much as I know, I hope someone with practical experience will provide a clearer explanation.

Those cached tasks will have scaled down rsc_fpops_est which is used to calculate estimated time, and rsc_fpops_bound which is used to calculate the time limit. The big increase in flops will make the times much shorter, but DCF will soon increase to fix the estimates. Unfortunately DCF isn't used for the limit.

                                                                  Joe

Good info Joe, I just put <flops> onto my main cruncher, got -17's. Will give this a try. Or is there a way to edit fpops in the app_info?

Regards,

A

You'd have to increase every single rsc_fpops_bound entry by some 3 magnitudes - one per task. Using the rescheduler is by far the less errorprone option.

Thanks, seems to be working fine, will keep a close watch though.


Regards,

A

---

I just noticed on my Nvidia GTX 460 box that it isn't getting squat either. No WUs at all...of any kind. All my other systems are chugging along just fine, getting new WUs...etc.

What is this new glitch this month?

I just noticed on my Nvidia GTX 460 box that it isn't getting squat either. No WUs at all...of any kind. All my other systems are chugging along just fine, getting new WUs...etc.

What is this new glitch this month?

Running two 460's here too. Nada, same as you.
No tasks available.

Regards,

A

Edit. Forget that, just got seven to download, not a lot, but things are beginning to move.

Regards

A

---

Interesting. Mine just started working too. What an amazing coincidence! Not. Must have stirred up the goblins at Berkeley.

Yup, that was my super secret Goblin Stirring Berkely Software, GSBS, (tm) coming online.

Regards,

A

:-)

---

I spoke too soon. I got a few WUs and then the faucet closed up tight again. It's been 16 hours since a new WU has been received. Why always this flaky behavior???

I spoke too soon. I got a few WUs and then the faucet closed up tight again. It's been 16 hours since a new WU has been received. Why always this flaky behavior???

Very odd I have been constantly bouncing off of the limit with mine.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

I think someone at SETI is just jealous that I'm running BOINC on 40 core servers...so they penalize me periodically. From the bizarro download behavior I regularly see, I can only conclude such a preposterous assumption.

I think someone at SETI is just jealous that I'm running BOINC on 40 core servers...so they penalize me periodically. From the bizarro download behavior I regularly see, I can only conclude such a preposterous assumption.

No, Virginia, it is not your Santa Claus. LOL.
I see the same preposterous messages even though I only have 8 rigs online.

---

"Time is simply the mechanism that keeps everything from happening all at once."

Help my AMD doesnt crunch very much at all. and the turn around time is long.its merged with
my intel and has no problems.

---

My Intel 970 machine with GTX480 has been running for weeks now with little or no WU's. Hardly any CPU WU's have been downloaded. Currently I have 7 GPU WU's ready to run and I get a message "Not requesting new tasks" when I connect. My AMD amchine with a GTX570 is doing a little better and has been downloading enough WU's to keep busy. My RAC is down from a one-time 50k to 16k now and I've slipped from No.1 in my group. My slower laptop and AMD 4400X2 are chunking along with all the work they can handle. What gives?????


Bob B.

---