Server side DCF for anon platforms

Message boards : Number crunching : Server side DCF for anon platforms
Message board moderation

To post messages, you must log in.

Previous · 1 · 2

AuthorMessage
Profile Miep
Volunteer moderator
Avatar

Send message
Joined: 23 Jul 99
Posts: 2412
Credit: 351,996
RAC: 0
Message 1020086 - Posted: 27 Jul 2010, 13:12:59 UTC

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!
ID: 1020086 · Report as offensive
Profile hiamps
Volunteer tester
Avatar

Send message
Joined: 23 May 99
Posts: 4292
Credit: 72,971,319
RAC: 0
United States
Message 1020122 - Posted: 27 Jul 2010, 14:55:24 UTC

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!
ID: 1020122 · Report as offensive
Profile perryjay
Volunteer tester
Avatar

Send message
Joined: 20 Aug 02
Posts: 3377
Credit: 20,676,751
RAC: 0
United States
Message 1020144 - Posted: 27 Jul 2010, 15:45:10 UTC

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
ID: 1020144 · Report as offensive
Josef W. Segur
Volunteer developer
Volunteer tester

Send message
Joined: 30 Oct 99
Posts: 4504
Credit: 1,414,761
RAC: 0
United States
Message 1020218 - Posted: 28 Jul 2010, 0:48:17 UTC - in response to Message 1020052.  

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
ID: 1020218 · Report as offensive
Bearcat

Send message
Joined: 10 Sep 99
Posts: 106
Credit: 10,778,506
RAC: 0
United States
Message 1020223 - Posted: 28 Jul 2010, 1:22:24 UTC - in response to Message 1020023.  

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 ?
ID: 1020223 · Report as offensive
Josef W. Segur
Volunteer developer
Volunteer tester

Send message
Joined: 30 Oct 99
Posts: 4504
Credit: 1,414,761
RAC: 0
United States
Message 1020242 - Posted: 28 Jul 2010, 2:38:53 UTC - in response to Message 1020223.  


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
ID: 1020242 · Report as offensive
Profile Dirk Sadowski
Volunteer tester

Send message
Joined: 6 Apr 07
Posts: 7105
Credit: 147,663,825
RAC: 5
Germany
Message 1020247 - Posted: 28 Jul 2010, 3:19:41 UTC - in response to Message 1020218.  

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!

ID: 1020247 · Report as offensive
Profile soft^spirit
Avatar

Send message
Joined: 18 May 99
Posts: 6497
Credit: 34,134,168
RAC: 0
United States
Message 1021565 - Posted: 1 Aug 2010, 8:06:01 UTC

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
ID: 1021565 · Report as offensive
Josef W. Segur
Volunteer developer
Volunteer tester

Send message
Joined: 30 Oct 99
Posts: 4504
Credit: 1,414,761
RAC: 0
United States
Message 1021672 - Posted: 1 Aug 2010, 15:08:34 UTC - in response to Message 1021565.  

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
ID: 1021672 · Report as offensive
Previous · 1 · 2

Message boards : Number crunching : Server side DCF for anon platforms


 
©2024 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.