I don't know why I just got this message a few minutes ago. Must have been in limbo somewhere. In theory anonymous apps shouldn't affect the credit calculations for other apps unless the anonymous platform app is doing a large amount of the work (like more than half). To the credit mechanism, and anonymous platform app is just another host_app_version entry. Of course, that's in theory, and I haven't yet convinced myself I understand either the theory or the practice.
David, might it help new app version releases if we seeded the pfc values of new app_versions with those of the previous app_version for the same platform, but with pfc_n set to some small value (say 50). I think that much of the cause of our problem was that the first few results that came back were compared against other results from new versions and that caused such bad pfc_avg and pfc_scale values that it was going to take 10,000 normal results to get back on track, but that wasn't going to happen because we were getting 90% resource aborts due to bad work estimates. We're starting to release the Astropulse GPU versions to the main project starting Tuesday but were going to do it very slowly, one version at a time, weeks apart, in hopes of not having this problem. On Wed, Jul 18, 2012 at 9:56 AM, Charles Elliott <[email protected]>wrote: > Has anyone considered the possibility that what is making the credit > computations incorrect on the Beta site is that I (and possibly others) are > running the stock Astropulse app as an anonymous app. Does the validator > allow for such a combination? To avoid a lot of discussion, I run the > stock > Astropulse app as an anonymous app so I can run an optimized app for S&H > cuda WUs and so I can run two instances of Astropulse per GPU, though the > latter might be possible with the Astropulse command line file; there are > no > instructions. > > 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.
