1) app_info entry: <app> <name>setiathome_v7</name> <user_friendly_name>SETI@home v7</user_friendly_name> </app> <file_info> <name>setiathome_6.99_windows_intelx86__opencl_ati_sah.exe</name> <executable/> </file_info> <app_version> <app_name>setiathome_v7</app_name> <version_num>699</version_num> <platform>windows_intelx86</platform> <avg_ncpus>0.05</avg_ncpus> <max_ncpus>0.05</max_ncpus> <plan_class>ati13ati</plan_class> <cmdline>-instances_per_device 4</cmdline> <flops>20987654321</flops> <file_ref> <file_name>setiathome_6.99_windows_intelx86__opencl_ati_sah.exe</file_name> <main_program/> </file_ref> <coproc> <type>ATI</type> <count>0.25</count> </coproc> </app_version>
2) Estimated GPU and CPU speeds: 20/12/2012 06:47:55 | | Processor: 4 GenuineIntel Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz [Family 6 Model 23 Stepping 7] 20/12/2012 06:47:55 | | Processor: 6.00 MB cache 20/12/2012 06:47:55 | | Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss htt tm pni ssse3 cx16 sse4_1 nx lm vmx smx tm2 pbe 20/12/2012 06:47:55 | | ATI GPU 0: Cayman (CAL version 1.4.1664, 2048MB, 2016MB available, 5632 GFLOPS peak) 20/12/2012 06:47:55 | | OpenCL: ATI GPU 0: Cayman (driver version CAL 1.4.1664 (VM), device version OpenCL 1.1 AMD-APP (851.4), 2048MB, 2016MB available) 3) Will check. ----- Original Message ----- From: "David Anderson" <[email protected]> To: <[email protected]> Sent: Thursday, December 20, 2012 11:15 PM Subject: Re: [boinc_dev] Unrecoverable 197 (0xc5) EXIT_TIME_LIMIT_EXCEEDED ... > What is the app_info.xml entry? > What are the estimated CPU and GPU speeds? > Does this happen also with 7.0.42? > -- David > > On 20-Dec-2012 11:08 AM, Raistmer wrote: >> Please, look at this host: >> http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=39394&offset=0&show_names=0&state=6&appid= >> >> For some reason (maybe recent driver change, maybe some project-side >> change) >> server decided that 4k seconds is max time app can spend for task. >> No matter what reason was (for now), it happened. >> And BOINC client started to kill one task after another. 4k spent - kill >> and >> so on. App making progress in those 4k seconds so such kill is pure waste >> of >> host resourses. >> But even that would be ok, if BOINC could accomodate somehow to new >> crunching times... but seems it can't! >> Task aborted with computation error hence its elapsed time doesn't mean >> anything for BOINC, it just discards it. >> That is, BOINC will kill tasks on host until all of them will be killed >> w/o >> any chance to recover from this situation. >> >> I consider this behavior as pure design flaw, some way should be provided >> for BOINC to accomodate to new crunching times. And even better if whole >> EXIT_TIME_LIMIT_EXCEEDED behavior will be re-designed. Its primary aim >> was >> to prevent endless loops and now it just kills host performance and lead >> to >> resourse waste, not save. >> >> Any wrong time estimate, especially at new app release and we see lots of >> such EXIT_TIME_LIMIT_EXCEEDED results killed for nothing. >> >> >> >> _______________________________________________ >> 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.
