Following a discussion at LHC http://lhcathomeclassic.cern.ch/sixtrack/forum_thread.php?id=3457 I've been looking (superficially) at the plan_class code. Seems that both sched_customize and plan_class_spec offer a sample SSE3 plan class, tested by finding the substring sse3 in p_model or p_features, depending on the age of the client. BUT: the clients don't return sse3 as a feature, they return pni instead. Intel processors (later than the Prescott CPU after which pni is named) support ssse3 (triple-s), but AMD processors don't. Because of the sub-string detection, it seems that the sse3 plan_class is operational for Intel processors, but blocked for AMD.
>________________________________ >From: Bernd Machenschalk <[email protected]> >To: Eric J Korpela <[email protected]> >Cc: [email protected] >Sent: Wednesday, 18 July 2012, 8:27 >Subject: Re: [boinc_dev] plan_class_spec > >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. > > > _______________________________________________ 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.
