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.
