strange - I just noticed new CPU have come in with much to low estimates, but new GPU are more or less as expected.

---

Carola
-------
I'm multilingual - I can misunderstand people in several languages!

Whenever I download VHars it seems to stop my downloads because they ALWAYS go into High Priority mode until they finish, WHY?

---

Official Abuser of Boinc Buttons...
And no good credit hound!

OK, I gave up. Removed my flops counts, got my opt-apps going right and am just going to let it rip. My to completion times jumped up a bit but not too much except for my AP tasks that jumped way high at first but are coming down slowly.

My GPU tasks have gone into high priority mode and are going after the VHARs. Bouncing around a bit but not too bad. At least I only have one suspended but it was one that had been running before I took the flops counts out.

---

PROUD MEMBER OF Team Starfire World BOINC

I use now the BOINC Rescheduler of Fred and have a min DCF of 0.5 and max DCF of 1.5 set with the config.xml file.

Current I have a DCF of 1.4x .

Strange is, that I have renamed .vlar WUs from GPU on the CPU, which have estimate times of ~ 25 hours. Normally a VLAR WU need little bit more than 2 hours.
Also I have a lot of CPU WUs, which have estimate times of ~ 6 mins. After searching, they are AR 0.31x WUs. I don't know the crunching time of this AR. An AR 0.44x WU would need ~ 100 mins. A shorty ~ 30 mins. So I guess an AR 0.31x WU would need ~ 1 hour.

The 0.31 WUs will probably take about 18% more time than the 0.44 WUs, so ~ 118 minutes.

So I have a lot of CPU WUs in my BOINC which have much more and much less estimate times.
I guess this are all renamed GPU WUs.

They will result in the famous -177 error?
How I could bypass this?
I need to add (in the config.xml file) something for the BOINC Rescheduler of Fred?

In past it was much easier to crunch SETI@home. ;-)

The setting to force a generous elapsed time limit to eliminate the -177 errors is on the Expert tab of Fred's BOINC Rescheduler, called "Limit rsc_fpops_bound". That's a lower limit, anything below is boosted.

For this transition time where there are tasks with both the splitter estimates and others with those estimates scaled by the Scheduler, it will be impossible to make everything work neatly. The range you've chosen for DCF is good, so with -177 errors prevented your computer should be able to complete the work it has. If most of it is done before Friday, at least the mix will be gone. Whatever bug made the Scheduler send 41 .vlar tasks to your GPU means that when those are checked by the Validator, the CPU speed will be affecting the GPU seconds/flop average. That may cause some continuing inaccuracy of estimates, but your GPU is doing enough tasks their effect on the average shouldn't be too great.

                                                                  Joe

Is there an easy how-to-do somewhere how I must calculate now my flops entries in my app_info.xml file?

Thanks!


EDIT: Which will work well with Fred's BOINC Rescheduler tool.

For those who had achieved a stable DCF with <flops> for the old standard, there's a very easy conversion: divide the old <flops> by the old DCF to produce the new <flops>. Mathematically the new DCF is found the same way, dividing the old DCF by the old DCF to produce 1.0.

                                                               Joe

So basically for those who followed your advice and adjusted the <flops> entries to achieve a DCF of 1.0 no changes are necessary, since old flops divide by old DCF (1.0) equals the same value ?

---

For those who had achieved a stable DCF with <flops> for the old standard, there's a very easy conversion: divide the old <flops> by the old DCF to produce the new <flops>. Mathematically the new DCF is found the same way, dividing the old DCF by the old DCF to produce 1.0.

                                                               Joe

So basically for those who followed your advice and adjusted the <flops> entries to achieve a DCF of 1.0 no changes are necessary, since old flops divide by old DCF (1.0) equals the same value ?

Just so.

Now if Dr. Anderson can find the bug keeping Astropulse applications from making any progress toward the 10 minimum to get the server-side adjustments, we'll have an idea when the adjustments will be in full effect. AP would be the last to get into operation anyhow, it's a shame it has been delayed even further by the bug.

                                                                Joe

I use now the BOINC Rescheduler of Fred and have a min DCF of 0.5 and max DCF of 1.5 set with the config.xml file.

Current I have a DCF of 1.4x .

Strange is, that I have renamed .vlar WUs from GPU on the CPU, which have estimate times of ~ 25 hours. Normally a VLAR WU need little bit more than 2 hours.
Also I have a lot of CPU WUs, which have estimate times of ~ 6 mins. After searching, they are AR 0.31x WUs. I don't know the crunching time of this AR. An AR 0.44x WU would need ~ 100 mins. A shorty ~ 30 mins. So I guess an AR 0.31x WU would need ~ 1 hour.

The 0.31 WUs will probably take about 18% more time than the 0.44 WUs, so ~ 118 minutes.

So I have a lot of CPU WUs in my BOINC which have much more and much less estimate times.
I guess this are all renamed GPU WUs.

They will result in the famous -177 error?
How I could bypass this?
I need to add (in the config.xml file) something for the BOINC Rescheduler of Fred?

In past it was much easier to crunch SETI@home. ;-)

The setting to force a generous elapsed time limit to eliminate the -177 errors is on the Expert tab of Fred's BOINC Rescheduler, called "Limit rsc_fpops_bound". That's a lower limit, anything below is boosted.

For this transition time where there are tasks with both the splitter estimates and others with those estimates scaled by the Scheduler, it will be impossible to make everything work neatly. The range you've chosen for DCF is good, so with -177 errors prevented your computer should be able to complete the work it has. If most of it is done before Friday, at least the mix will be gone. Whatever bug made the Scheduler send 41 .vlar tasks to your GPU means that when those are checked by the Validator, the CPU speed will be affecting the GPU seconds/flop average. That may cause some continuing inaccuracy of estimates, but your GPU is doing enough tasks their effect on the average shouldn't be too great.

                                                                  Joe

Again.., thanks a lot!

---

CPU numbers are back to being about 200-300% over estimation of time involved.

I do not understand the math. But it keeps making these massive jumps, then slowly readjusting to "normal" and then making the huge jumps again.

This is not anon platform, not customized, straight 6.10.58 boinc. And honestly, it feels like I have been boinc'ed again.

The base numbers seem terrible.. and the adjustment keeps getting reset. WHY??
I realize once was going back to server side estimates, but how many times does that get reset??

---

Janice

CPU numbers are back to being about 200-300% over estimation of time involved.

I do not understand the math. But it keeps making these massive jumps, then slowly readjusting to "normal" and then making the huge jumps again.

This is not anon platform, not customized, straight 6.10.58 boinc. And honestly, it feels like I have been boinc'ed again.

The base numbers seem terrible.. and the adjustment keeps getting reset. WHY??
I realize once was going back to server side estimates, but how many times does that get reset??

The DCF jumped up by a factor of about 3 because Task 1663754667 was a reissue of an older VLAR to your GPU. Those should become quite rare within 6 weeks or so.

The "going back to server side estimates" was only for anonymous platform hosts, running stock you've been on those all along. But the server side assumes the estimates produced by the splitter are basically correct and only need scaling. That is approximately true for CPU processing here, but GPUs react differently and VLAR estimates are off by a factor of 3 for your GT 220 and even worse for a GTX 295 or similar.

                                                                Joe