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 > 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.
