On Apr 25, 2009, at 9:11 PM, David Anderson wrote: > "Overworked" is always relative to a particular resource type, > and is based on the LTD for that resource type. > > [email protected] wrote: >> Earlier you indicated that CUDA LTD was not in the same units as >> CPU LTD. >> However, this brings up a problem. The concept of overworked is in >> the >> same units as CPU LTD (wall seconds). >> >> This makes it much more difficult to determine if an application is >> overworked or not if there is a CUDA processor involved. The >> comparison of >> CUDA LTD < overworked cuttoff LTD does not work as there is a units >> mismatch. Sort of like comparing seconds to days. There is >> probably a >> conversion that could be applied, but it has to be done carefully.
Yes, well, it is not working in real life. As I noted in an earlier post we have asymetric debt growth when there is only one project of a resource class attached and over time that chokes off the ability to obtain the correct amount of work. Sadly, the client does not track well which projects have and don't have GPU work which is why I suggested we add an explicit parameter such as the no cpu work of SaH. The only additional note is that we have to also track if the client is accepting work from that atttached project. In my case I have SaH Beta and GPU Grid attached for GPU work at this time but I have SaH Beta in NNT unless I know that GPU Grid is going off line. Though I will attach to more GPU projects as they come on line, we cannot count on this as many participants will only want to attach to one and only one project for some resource classes. In these cases, any successful work fetch should reset the debt to zero. (If I understand the logic correctly, I know my manual reset of debt solves my trouble every few days). _______________________________________________ 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.
