Hi! >The question, however, is this: is BOINC as smart as a 4th grader - can it avoid falsely >claiming that work units won't finish on time, thus misleading users into aborting work >units that appear to have absolutely no chance of making their deadline?
Maybe the real problem is that the info BOINC manager displays as an estimate has no measure of confidence or uncertainty attached (it lacks error bars, if you want). If an estimate is just "it will take 100 hrs, 10 min, 5 sec" , updated every second, the user reaction will (understandably) be different compared to something like (say) "100 hrs (+/- 80 hrs)". No matter what scheme is used for the estimation, there will always be some uncertainty and while I'm not familiar with the BOINC code on the projected runtime, if things like the standard deviation of runtime per task is kept (I think this was mentioned), plus some [new] project supplied measure of uncertainty of the flops estimate for a workunit, it might be possible to give a better (more useful, less misleading) estimate by including an uncertainty. Just my 2 cents. Cheers HBE ----------------------------------------------------------------- Heinz-Bernd Eggenstein Max Planck Institute for Gravitational Physics Callinstrasse 38 D-30167 Hannover, Germany Tel.: +49-511-762-19466 (Room 037) From: William <[email protected]> To: Jon Sonntag <[email protected]>, "[email protected]" <[email protected]>, Cc: "BOINC Developers Mailing List @berkeley.edu" <[email protected]> Date: 02/13/2014 12:53 AM Subject: Re: [boinc_dev] Estimated Time Remaining, frictional reporting ... Sent by: "boinc_dev" <[email protected]> The question, however, is this: is BOINC as smart as a 4th grader - can it avoid falsely claiming that work units won't finish on time, thus misleading users into aborting work units that appear to have absolutely no chance of making their deadline? Signs point to NO. ~~~~~ "Rightful liberty is unobstructed action according to our will within limits drawn around us by the equal rights of others. I do not add 'within the limits of the law' because law is often but the tyrant's will, and always so when it violates the rights of the individual." - Thomas Jefferson On Wednesday, February 12, 2014 5:28 PM, Jon Sonntag <[email protected]> wrote: If after 5 minutes, a workunit is 10% done and after 10 minutes it is 20% >done, I don't need a domain expert. A 4th grade student should be able to >calculate that it will take a total of 50 minutes to complete and that 40 >minutes remain. > >Jon Sonntag > >P.S. I went to a tax professional once. They charged a lot and they got it >wrong. The IRS corrected it and sent me a refund. > > > >On Tue, Feb 11, 2014 at 6:18 AM, Charles Elliott <[email protected]>wrote: > >> Although I am a CS grad student, I urge you to reconsider choosing CS grad >> students to work on this problem and consider instead using domain experts >> in statistics and/or Operations Research or Systems, or perhaps even an >> interdisciplinary team. Old research shows that it is much more >> cost-effective to hire domain experts and teach them to program computers >> than it is to hire CS grads and try to teach them the domain. Suppose your >> income tax preparation was a complex process. Which would you want do it: >> a >> CS grad who wrote the fastest program possible, or a tax law expert who >> could save you months of work on an IRS tax audit and keep you out of jail? >> >> Charles Elliott >> >> -----Original Message----- >> From: boinc_dev [mailto:[email protected]] On Behalf Of >> David Anderson >> Sent: Monday, February 10, 2014 10:58 PM >> To: [email protected] >> Subject: Re: [boinc_dev] Estimated Time Remaining, frictional reporting ... >> >> In general we've put statistics-gathering into server rather than client >> because >> - it gives uniform data over the entire host population >> - it puts the data all in one place >> >> Currently these statistics are just the bare essentials: >> mean and standard deviation of elapsed time, turnaround time, and >> credit-related quantities. >> We maintain these per (host, app version) and per app version. >> We use them to estimate job duration and to compute credit. >> >> As you point out, there are many other types of info we could track, and >> many visualizations that could offered. >> This is an area were having a few CS grad students working on BOINC would >> be >> a big help. >> >> -- David >> >> On 10-Feb-2014 4:01 PM, Max Power wrote: >> > >> > Many types of distributed computing applications don't due uniform >> > processing (and reporting on percent done) like SETI, Astropulse or >> > Einstein ... and the biological science applications (and image >> > rendering ones) have taken some time to discipline the reporting of >> percent done. >> > >> > What the BOINC Client does not do is use the hashsums of computing >> > applications (as sometimes they run in pairs as in Climate Prediction) >> > to form a local knowledge base of >> > >> > -- work unit size (average, median, standard deviation) >> > -- work unit computation length (average, median, standard deviation) >> > -- completed work unit average size (average, median, standard >> > deviation) >> > -- disk use (average, median, standard deviation) >> > -- these could be uplinked to the BOINC design groups and the projects >> > themselves ... as you probably have to do an SQL query to find this >> > stuff out >> > -- THE "STATS" tab is almost totally devoid of usable statistics ... >> > and the ones above relating to runtime are graphable and usable ... >> > >> > >> > I am not saying this will fix the wonky estimated run time problem ... >> > only regular application reporting to the BOINC client will ever do >> > that. However, the averaged knowledge from these parameters could >> > improve it when the daft application is not reporting. >> > >> > >> > MP, DSN @ H >> > >> > >> > -----Original Message----- From: McLeod, John >> > Sent: 10 February 2014 05:48 >> > To: Jon Sonntag ; BOINC Developers Mailing [email protected] >> > Subject: Re: [boinc_dev] Estimated Time Remaining >> > >> > Not all applications report smooth % complete. So the calculation of >> > time remaining involve the initial estimate as well. Given the bad >> > information given for both % complete and initial estimate, there is >> > no method of predicting how much longer the task will take that is >> > completely right. The most reliable appears to be to combine the >> > initial estimate the DCF (if in use for the project) the % complete, >> > and the time spent already (the only really well known item in the list) >> to come up with an estimate. >> > >> > >> > _______________________________________________ >> > 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. >> >_______________________________________________ >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.
