Message boards :
Number crunching :
GPU in the Lunatics' apps
Message board moderation
Previous · 1 · 2
Author | Message |
---|---|
Josef W. Segur Send message Joined: 30 Oct 99 Posts: 4504 Credit: 1,414,761 RAC: 0 |
Fred J. Verster wrote: ---[SNIPPED]--- For anonymous platform hosts with any significant amount of cached work, making an abrupt large adjustment of flops isn't a good idea. The APRs for GPU work are based on runtimes for each task, so are affected strongly by how many tasks you run simultaneously; changing from 1 to 2 tasks or vice versa would nearly double or halve the expected rate. But for any application where the APR has had time to stabilize, adjusting <flops> toward that APR in steps would make sense to me. Your i7 2600 with 2 ATI 5870 system has a Whetstone benchmark around 3.27e09 and APRs around 21e09 for MB CPU, 68e09 for MB GPU, 42e09 for AP CPU, and 200e09 for AP GPU. For that host, I'd set the <flops> in steps over several days, something like: Day1 Day2 Day3 Day4 MB CPU 6e09 12e09 21e09 APR MB GPU 8e09 20e09 50e09 APR AP CPU 8e09 16e09 32e09 APR AP GPU 9e09 24e09 64e09 170e09 APR That's assuming you won't have much more than a one day cache, the idea is to have tasks which were scaled for a particular flops value be completed before you increase the flops too much. {edit} As a final note, it might be wise to boost the rsc_fpops_bound values to avoid possible -177 execution time errors during the adjustment period, either by direct editing of client_state.xml or using Fred's Boinc Rescheduler. Joe |
Fred J. Verster Send message Joined: 21 Apr 04 Posts: 3252 Credit: 31,903,643 RAC: 0 |
Fred J. Verster wrote:---[SNIPPED]--- Thanks very much, I'll save your info and try this. (And it isn't necessary, setting a large cache, if workflow is about D'loading a few MBs, whithout unnecessary delays, compute them and return them, IMHO :)) |
kittyman Send message Joined: 9 Jul 00 Posts: 51469 Credit: 1,018,363,574 RAC: 1,004 |
<to_flop_or_not_to_flop>0</to_flop_or_not_to_flop> Meeeowwwwwwr. That is the question. "Freedom is just Chaos, with better lighting." Alan Dean Foster |
Kevin Olley Send message Joined: 3 Aug 99 Posts: 906 Credit: 261,085,289 RAC: 572 |
<to_flop_or_not_to_flop>0</to_flop_or_not_to_flop> I am hoping I don't have to, with the limits in place this machine is managing ok, if I can get the right mix of AP's and MB's on CPU I will get enough GPU WU's to keep it happy. When the limits come off the worst problem I can see is getting flooded with AP's (highly unlightly) or VLAR's, but with careful use of Reschedular I can hopefully avoid that. Kevin |
HAL9000 Send message Joined: 11 Sep 99 Posts: 6534 Credit: 196,805,888 RAC: 57 |
OK, I finally gave in on my Q8200 with an ATI 4850 GPU. The estimated times for AP on the GPU was so extremely out of reality, it finishes 2 AP's in about 8 hours, but the estimations which never really came down even after hundreds of finished AP's on the GPU, was 28-35 hours per AP, it went down when one AP on the GPU was finished, but as soon as one AP on the CPU finished, it went back to more than 3 times the real value again. With all the talk of taking flops out because it "wasn't needed" I left it in there. As it doesn't hurt anything if it isn't needed, but if it is then bang it is already there. If it ain't fixed don't broke eet. SETI@home classic workunits: 93,865 CPU time: 863,447 hours Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[ |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14654 Credit: 200,643,578 RAC: 874 |
Yes, just at the moment <flops> will be needed by anyone who wants to maintain consistency of estimated runtimes while running two or more SETI applications. It's not needed if you always run a single application, but if you run both CPU and GPU, or both AP and MB, or any such mixture, you'll get erratic runtime estimates without <flops>. This is because of the bodged server fix to the error -177 problem. But as WinterKnight pointed out, It is now 3 months since that little contretemps, and neither BOINC nor SETI are showing much urgency about fixing it. So you may as well leave <flops> in there, as a workround for the workround.... |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14654 Credit: 200,643,578 RAC: 874 |
That makes sense. Because of the way the botched workround was applied, it made a fast machine look like a slow machine - or more specifically, the fast bits of a fast GPU look like a slow CPU. So your client is saying "I'm fast", and the server is saying (falsely), "no you're not, you're slow". That's when the estimates go crazy. But for a slow machine, both the client and the server agree that it's slow, and they get along a lot better ;-) |
zoom3+1=4 Send message Joined: 30 Nov 03 Posts: 65793 Credit: 55,293,173 RAC: 49 |
That makes sense. Because of the way the botched workround was applied, it made a fast machine look like a slow machine - or more specifically, the fast bits of a fast GPU look like a slow CPU. So your client is saying "I'm fast", and the server is saying (falsely), "no you're not, you're slow". That's when the estimates go crazy. Sounds like the DCF is swinging, up and then down, PC says one way, Server says go the other way, that is nuts. The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14654 Credit: 200,643,578 RAC: 874 |
That makes sense. Because of the way the botched workround was applied, it made a fast machine look like a slow machine - or more specifically, the fast bits of a fast GPU look like a slow CPU. So your client is saying "I'm fast", and the server is saying (falsely), "no you're not, you're slow". That's when the estimates go crazy. Exactly. That is why, each week, we ask them to take the next step back towards smooth running. Without success, so far. |
zoom3+1=4 Send message Joined: 30 Nov 03 Posts: 65793 Credit: 55,293,173 RAC: 49 |
That makes sense. Because of the way the botched workround was applied, it made a fast machine look like a slow machine - or more specifically, the fast bits of a fast GPU look like a slow CPU. So your client is saying "I'm fast", and the server is saying (falsely), "no you're not, you're slow". That's when the estimates go crazy. So that's it, Thanks Richard, yer a real Lion Heart. :D Keep asking, meanwhile I'll just flop around It. The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's |
©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.