Also, using version 301.42 of the Nvidia display driver, Beta Astropulse run as an anonymous app, uses about 70% of the CPU when one WU finishes and another is started on the same GPU. When BoincMgr is restarted in this case the CPU percentage slowly declines to single digits or just above. This behavior does not occur on another computer that uses version 266.58 of the display driver. A day or two of testing would have to be done to determine whether restarting the orphan WU when one WU finishes on a GPU that is processing two WUs results in a higher credit per hour for the system in total, since when GPU Beta Astropulse WUs use a lot of CPU they finish fairly quickly.
Charles Elliott > -----Original Message----- > From: [email protected] [mailto:boinc_dev- > [email protected]] On Behalf Of Eric J Korpela > Sent: Wednesday, July 18, 2012 12:03 PM > To: Bernd Machenschalk > Cc: [email protected] > Subject: Re: [boinc_dev] plan_class_spec > > The flops estimation code has been hard for me to get my brain around. > It's possible that the problem is somewhere in the change from > separate ATI and CUDA coprocessor support to a single GPU requirements > structure. > I've attached my sched_customize.cpp. I think I've made it compatible > with the stock version now, so I could check it in. But I don't want > to mess anyone else up so I haven't. > > > > On Wed, Jul 18, 2012 at 12:27 AM, Bernd Machenschalk < > [email protected]> wrote: > > > Hi Eric! > > > > As the original author of that plan_class_spec code I have to admit > > that the flops scaling etc. is still something of a mystery to me, > and > > although I changed it a few times I am pretty sure I didn't get this > right. > > Apparently the latest rework by David didn't fix it either, although > > the latest version should use the functions provided in > > sched_customize.cpp and thus have more code in common with it. > > > > Could you send me (or point me to) SETIs sched_customize.cpp? I hope > > it could help me to understand and fix the problem. > > > > Best, > > Bernd > > > > > > On 14.07.12 18:32, Eric J Korpela wrote: > > > >> I've spent a few weeks in the SETI@home beta trying to move from > some > >> highly customized plan classes to the plan_class_spec mechanism for > >> some OpenCL apps. It's not working, and at this point I'm going to > >> go back to the highly customized plan classes even though they are > >> difficult the keep synced with changes to the source tree. > >> > >> The best I can figure out is that a lot of the scheduling and credit > >> mechanisms are having problems. Many of the problems seem to have > >> something to do with flop scaling. In sched_customize.cpp where > >> customizable GPU plan classes live, a flops scale is applied to the > >> GPUs processing rate. In plan_class_sched, it's applied to the CPUs > processing > >> rate even for GPU plans. The "sample" plan_class_spec.xml file has > >> values > >> that would be suitable for the sched_customize method do not work > for > >> plan_class_spec at all. The scheduler itself is very confused about > >> what it means. If you put a value of 10 for flops_scale in > >> plan_class_spec.xml, it will multiply the cpu benchmarks by 10 to > get > >> the processing rate, but then it does an incorrect calculation of > >> processing rate based on PFC. > >> Most GPUs seem to get estimated at about 100MFLOP from the bad PFC > >> calculation. Credits granted for GPU work done come in about > 1/500th > >> of what they should be. Even beta testers get annoyed when the see > >> 0.86 credits for something that should have been 700. > >> > >> Unfortunately there's not a a lot of source commonality between the > >> two mechanisms, so anything I learned writing plan classes is lost > in > >> plan_class_spec. So I'm giving up on fixing it myself. > >> > >> If you're planning to use the plan_class_spec mechanism, I would > hold > >> off until it's fixed. > >> ______________________________**_________________ > >> boinc_dev mailing list > >> [email protected] > >> > http://lists.ssl.berkeley.edu/**mailman/listinfo/boinc_dev<http://lis > >> ts.ssl.berkeley.edu/mailman/listinfo/boinc_dev> > >> To unsubscribe, visit the above URL and (near bottom of page) enter > >> your email address. > >> > > > > _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
