I tried the new credit system, for most of the hosts it works, however I've seen some unexpected values here and there. For example, hosts getting almost 10 times more credit that I assigned for certain WUs (and around 7-8 times more than average from the default credits). Probably it has something to do (or is somehow related to) with corrupted (?) fields in host_app_version. Here at my project it doesn't look so bad, there are few hosts with average processing rate extremely high (hundreds of thousands) and probably these are the same hosts that get strangely high credits. I was looking at one of these weird hosts, most of the tasks it returned were invalid (broken app) and somehow it got processing rate about 9000, while an average quad core CPU gets 7-9.
The actual difference between what I assigned for the workunits and what the credit system assigns is not that big (on average perhaps 20-30%), so probably I'll try the new credit system in nearest future, at least for CPU jobs. I don't have GPU app yet, but I've heard from dnetc.net's admin that they tried the new system and it didn't work very well, credits granted for ATI-GPU tasks were close to those granted for CPU tasks, while the GPU tasks are much longer (I don't know the exact value but it might be up to 100 times longer), so that's just unfair IMO. I'm upgrading my sources right now and I'll report if the fixed code works. /TJM http://www.enigmaathome.net On Wed, 03 Nov 2010 15:07:23 -0700 David Anderson <[email protected]> wrote: >I checked in a possible fix. > >However: why use --credit_from_wu? >I strongly encourage using the default credit system. > >-- David > >On 03-Nov-2010 2:00 PM, Slawomir Rzeznicki wrote: >> Just tried, it works fine. >> As far as I remember values returned by the >>parse_double() were close to 2^31, >> changing randomly. >> Maybe that's because there's something else broken, I >>left the validator running >> overnight and probably it entered infinite loop, because >>on morning the drive >> which it logs to was completely filled and the log had >>tens of gigabytes. >> I started looking at the parse_double after I found out >>that the function >> get_credit_from_wu reads xml_doc and parses it, but >>there's no sign of that in >> the validator log (line 359 in validator.cpp should log >>it), and validator still >> uses default credit system. >> As far as I know at least one more project admin had >>exactly the same problem >> and he even warned me before I upgraded the code, saying >>that it's likely to run >> into problems. >> On Wed, 03 Nov 2010 13:08:46 -0700 >> David Anderson <[email protected] >><mailto:[email protected]>> wrote: >> >I'm not seeing this problem. >> >Can you please try running this program: >> > >> >#include <stdio.h> >> >#include <stdlib.h> >> > >> >int main() { >> > double x = atof("5.14343</credit"); >> > printf("%f", x); >> >} >> > >> >Maybe it's an issue with the gcc version. >> > >> >-- David >> > >> >On 03-Nov-2010 2:53 AM, Slawomir Rzeznicki wrote: >> >> Hello, >> >> >> >> Yesterday I'noticed that --get_credit_from WU >>doesn't >> >>work with the latest >> >> validator code, probably it's broken since the >>removal >> >>of old credit system >> >> (can't verify that because TRAC requires permissions >>to >> >>view changes, that's >> >> weird because 2 days ago it didn't). >> >> >> >> I've done a lot of debugging and traced the problem >>to >> >>inline parse_double() >> >> in lib/parse.h. As far as I can see, this function >>can't >> >> parse<credit>x.xxxx</credit> if there is no space, >>tab, >> >>return or other >> >> whitespace after the number, y = atof(p+strlen(tag) >> >>returns strange values >> >> (extremely high numbers) for inputs like >> >>"5.14343</credit>" when the p+len >> >> points correctly at the beginning of the float. >> >> >> >> I think that the function could be easily replaced >>with >> >> XML_PARSE::parse_double(), but since I'm not C/C++ >> >>programmer I failed to do >> >> it. >> >> >> >> /TJM http://www.enigmaathome.net >> >> _______________________________________________ >> >>boinc_dev mailing list >> >> [email protected] >><mailto:[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. _______________________________________________ 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.
