Unfortunately, some projects take the easy cop-out - applying a massive rsc_fpops_bound to circumvent resource limit exceeded, instead of resolving it properly from first principles.
I suspect that some of the smaller projects have enough on their plate getting their heads round their own scientific research needs, and don't have enough time and energy left to switch into "computer scientist" mode and concentrate on the boincification of their application and workflow. >________________________________ > From: Oliver Bock <[email protected]> >To: David Anderson <[email protected]>; Rytis Slatkevičius ><[email protected]> >Cc: BOINC Developers Mailing List <[email protected]> >Sent: Monday, 17 February 2014, 9:22 >Subject: Re: [boinc_dev] Estimated Time Remaining, frictional reporting ... > > >On 14/02/14 8:30 , David Anderson wrote: >> I'd prefer to figure out why the static estimates are off. >> If an app's jobs are of a size proportional to wu.rsc_fpops_est, >> the static estimates should be almost exact, even for a host's first jobs. > >The static estimates are often very rough ones because it's sometime not >that easy to get a handle on accurate ones. In the extreme the estimate >gets just set in such a way that you don't run into a "resource limit >exceeded" issue - so you add at least some headroom. However, even in >such a case you may know that your app will behave more or less linear. >This is why I think having the said opt-in flag would be very useful for >such apps. > > >Cheers, >Oliver > > > >_______________________________________________ >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.
