We've had similar issues with the n-body simulations we're doing on milkyway@home. The runtime of the workunits is fairly dependent on the initial random distribution of bodies, and the runtimes can vary from a couple hours to a couple days.
It would be nice to get away from having to specify the RSC_FPOPS_EST for each workunit, especially as in our case it can cause workunits to be terminated prematurely by the clients. I don't suppose you've run into this problem as well? On Nov 7, 2011, at 12:25 PM, Richard Haselgrove wrote: > Part 2 of this research: Credit > > Because the NumberFields tasks are so variable (from 2 ro 300,000 seconds), > I've been looking at the rate that credit has been awarded - Credits per hour > (of runtime) gives a nice human-scale value. > > Here are the results for my four hosts at NumberFields. All four were > attached at the same time (note the consecutive HostIDs): in particular, the > two Q6600 hosts have identical hardware. > > http://img46.imageshack.us/img46/826/numberfieldscreditperho.png > > The problem is that the rate at which credit is granted depends critically on > the host APR value. With a non-deterministic project, especially in the early > days after attachment, APR is heavily influenced by the random processing > time of the early tasks. The credit/hour for all hosts were tightly grouped > for the first 10 tasks, when APR is effectively ignored, but thereafter they > diverge spectacularly. Hosts 1288 and 1289 happened to get short tasks first, > so APR was artificially high when it was first used for credit calculation: > hosts 1290 and 1291 happened to draw longer-running tasks. > > It was host 1290 which received the 300,000 second task > (http://numberfields.asu.edu/NumberFields/result.php?resultid=292439), and > was awarded 4,500 credits (in round figures). At very much the same time, the > identical host 1291 returned > http://numberfields.asu.edu/NumberFields/result.php?resultid=317447, getting > almost the same credit for just 43,000 seconds of work. > > It's discrepancies like that which lead users, and project administrators, to > distrust CreditNew. I think it needs more work, especially if BOINC is going > to continue to support non-deterministic projects. > _______________________________________________ > 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. --------------------------------------------------------------------------- Travis Desell, Assistant Professor University of North Dakota - Dept. of Computer Science [email protected] - cell: 518-867-1054 Streibel Hall Room 220 - office: 777-701-3477 3950 Campus Road Stop 9015 Grand Forks, North Dakota 52802-9015 Homepage ( http://people.cs.und.edu/~tdesell/ ) MilkyWay@Home ( http://milkyway.cs.rpi.edu/ ) DNA@Home ( http://dnahome.cs.rpi.edu/ ) Worldwide Computing Laboratory ( http://wcl.cs.rpi.edu/ ) ---------------------------------------------------------------------------- _______________________________________________ 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.
