I have some 8 core machines that get hot and the TThrottle app keeps my CPU utilization down at times so my machine doesn't get overly hit. I very often go over the estimated time to completion. My situation doesn't have anything to do with android but I'm scared sometime that my results will be flagged because they run longer than anticipated.
Shelby > On Jun 9, 2014, at 4:52 PM, Juha <[email protected]> wrote: > > On 7 June 2014 12:51, Richard Haselgrove <[email protected]> > wrote: > >> Three of the four hosts have never returned a valid result (total credit >> zero), so they have never had a chance to establish an APR for use in >> runtime estimation: runtime estimates and bounds must have been generated >> by the server. >> >> It seems - from these results, and others I've found pending on other >> machines - that SIMAP tasks on Android are aborted >> with EXIT_TIME_LIMIT_EXCEEDED after ~6 hours elapsed. For the new batch >> released today, SIMAP are using a 3x bound (which may be a bit low under >> the circumstances): >> >> <rsc_fpops_est>13500000000000.000000</rsc_fpops_est> >> <rsc_fpops_bound>40500000000000.000000</rsc_fpops_bound> >> >> so I deduce that the tasks when first issued had a runtime estimate of ~2 >> hours. >> >> My own tasks, on a fast Intel i5 'Haswell' CPU (APR 7.34 GFLOPS), take >> over half an hour to complete: two hours for an ARM device sounds >> suspiciously low. The only one of my Android wingmates to have registered >> an APR ( >> http://boincsimap.org/boincsimap/host_app_versions.php?hostid=771033) is >> showing 1.69 GFLOPS, but I have no way of knowing whether that APR was >> established before or after the task in question errored out. > > Two hours isn't terribly bad estimate. There are Android hosts that > complete SIMAP tasks in 2-3 hours. I believe SIMAP does mostly integer math > so the tasks aren't slowed down as badly as tasks for some other projects. > > What's interesting with the SIMAP Android tasks that get killed with > EXIT_TIME_LIMIT_EXCEEDED is the great difference between CPU time and > elapsed time. The tasks always have a couple hundred seconds of CPU time > and 20 000 - 30 000 seconds elapsed time. I can't remember ever seeing an > Android task with thousands of seconds of CPU time and then getting killed > by using too much time. > > I wonder if the app crashes without BOINC noticing or the task is suspended > for whatever reason but BOINC forgets about the suspending. The Samsung's > Power Sleep app appears to be using BOINC 7.3.0. The Android 7.3.x versions > aren't mentioned in Release notes or Version history pages so it's pretty > hard to tell what fixes later versions have or if 7.3.0 was even ever > released. > > Now I'm not saying that BOINC isn't capable of making bad decisions. > Consider the following: > > Normally tasks for a project runs for 1 hour on a host. The project has > chosen to use max runtime of 3x estimated runtime. Runtimes for the tasks > for this project are easy to predict and always correct. > Now lets say the owner of the host decides to play some game. The game uses > about 70% of CPU time, leaving the rest for BOINC. > Since BOINC now gets about 30% of CPU cycles a task for the project needs a > bit over three hours of wall clock time before it's done. But once three > hours has passed BOINC decides that the now almost complete task has been > running too long and kills it. > > This wasn't a hypothetical example :( > > Maybe elapsed time is best you have for GPU apps but for CPU apps it > doesn't work. There is no reason why the app would always get 100% CPU time > and very often, if not most of the time, it doesn't. I mean, the reason why > we have BOINC is that users can run their computers the way they like and > BOINC gets whatever CPU time is left from user's programs. > > I don't think fixing this by increasing the runtime multiplier is the right > solution. Instead of letting project people work on their apps and deciding > how much runtime their app needs and with how much variation you now force > them to consider how the volunteers use their computers. > > (Ok, basing the decision purely on used CPU time wouldn't work in every > case either. For example, the app could get stuck waiting for an event that > never comes.) > > -Juha > _______________________________________________ > 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.
