Thanks jm7, Like I say I'll need to test this and see if this actually happens on this build (6.11.4) over a prolonged period Maybe the event log message "11/08/2010 21:27:01 | | [work_fetch] target work buffer: 0.86 + 388800.00 sec" should be changed to reflect what the real target work buffer is? As the calculation below is forcing Boinc to request a lower buffer than it is stating. This is going to mislead/confuse users about exactly how much work Boinc is trying to request
Ghost > To: [email protected] > From: [email protected] > Date: Tue, 10 Aug 2010 08:04:04 -0400 > CC: [email protected]; [email protected] > Subject: Re: [boinc_dev] Work Fetch Request Logic > > <on_frac>0.404988</on_frac> > > This should be cutting the requests by 60% all by itself. > > The calculation should be: 0.404988 * 0.999558 * shortfall for the work > request. > > jm7 > > > > Jamie Tiller > <ghost0...@hotmai > l.co.uk> To > <[email protected]> > 08/09/2010 04:54 cc > PM <[email protected]>, > <[email protected] > > > Subject > RE: [boinc_dev] Work Fetch Request > Logic > > > > > > > > > > > Included both time_stats and net_stats > > <time_stats> > <on_frac>0.404988</on_frac> > <connected_frac>0.811280</connected_frac> > <active_frac>0.999558</active_frac> > <last_update>1281386658.730200</last_update> > </time_stats> > <net_stats> > <bwup>11983.721332</bwup> > <avg_up>8510916.840124</avg_up> > <avg_time_up>1281386662.966200</avg_time_up> > <bwdown>23045.015106</bwdown> > <avg_down>82112700.670026</avg_down> > <avg_time_down>1281378942.015200</avg_time_down> > </net_stats> > > > To: [email protected] > > From: [email protected] > > Date: Mon, 9 Aug 2010 16:18:24 -0400 > > CC: [email protected]; [email protected] > > Subject: Re: [boinc_dev] Work Fetch Request Logic > > > > >From your client_state.xml file, what are the time_stats? > > > > jm7 > > > > > > > > Jamie Tiller > > <ghost0...@hotmai > > l.co.uk> To > > <[email protected]>, > > 08/09/2010 04:08 <[email protected]> > > PM cc > > <[email protected] > > > > > Subject > > RE: [boinc_dev] Work Fetch Request > > Logic > > > > > > > > > > > > > > > > > > > > > > Ok, > > > > I'm not seeing this at the moment, although I've not been monitoring the > > work fetch requests. > > Everytime that Boinc does a work fetch I see the default 4.5 days being > > requested from the cache settings. > > I'll run Boinc with the current settings for a couple of weeks and see if > > it starts to adapt better to the actual uptime per day and adjusts the > work > > fetch's accordingly > > > > Thanks > > > > > To: [email protected] > > > From: [email protected] > > > Date: Mon, 9 Aug 2010 08:25:35 -0400 > > > CC: [email protected]; [email protected] > > > Subject: Re: [boinc_dev] Work Fetch Request Logic > > > > > > The client also tracks this, and should reduce the work fetch requests > > > after a couple of weeks of running part time. The information should > > > already be incorporated into the work fetch request. > > > > > > Yes, new clients can fetch more work than makes sense for clients that > > are > > > off most of the time, but they should reduce the requests after enough > > > information is gathered. > > > > > > jm7 > > > > > > > > > > > > Jamie Tiller > > > <ghost0...@hotmai > > > l.co.uk> To > > > Sent by: <[email protected]> > > > <boinc_dev-bounce cc > > > [email protected] > > > u> Subject > > > [boinc_dev] Work Fetch Request > > > Logic > > > 08/07/2010 07:29 > > > AM > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > Is it possible that the work fetch request system can be subtly > changed? > > > At > > > the moment, the user set's a cache by days in the client or the project > > > web site, this cache is then converted into seconds and the work fetch > > > logic will try to fill this cache. > > > For computers that are on and > > > crunching 24/7 this logic is fine, but for computers that only crunch > > > for a % of the day then this leads to them overfilling their cache and > > > possibly having work units time out or go to High Priority mode as they > > > will not finish in time. > > > > > > For example, I currently have a cache > > > set to 4.5 days but only crunch for about 8 hours per day. The work > > > fetch request logic is currently asking for 0.86 + 388800.00 seconds of > > > work so potentially giving me 108 hours of work. Given the fact that in > > > reality I will only crunch for 36 hours (129600 seconds) of that 108 > > > hours this is a massive overfill of the cache. > > > >From the project > > > websites we already track various statistics about how Boinc runs and > is > > > connected to the network etc, could we not utilise these figures to be > > > able to give a realistic figure on that hosts up time and then use that > > > figure in the work fetch request logic? > > > > > > Ghost > > > > > > _______________________________________________ > > > 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.
