Hi, So I've done some more prolonged testing regarding this, currently on build 6.11.4, Windows 7 64bit. Have my cache set to 4 days (86400 * 4 = 345600 seconds)
>From my client_state:
<time_stats>
<on_frac>0.501165</on_frac>
<connected_frac>0.702491</connected_frac>
<active_frac>0.999492</active_frac>
<last_update>1282324678.690800</last_update>
</time_stats>
So if the work fetch logic is requesting the correct amount of work, then Boinc
should request
<on_frac>0.501165</on_frac> * <active_frac>0.999492</active_frac> * shortage of
work.
If we use my nvidia GPU (GTX465) just as the example:
20/08/2010 18:25:59 | | [work_fetch] NVIDIA GPU: shortfall 294010.03 nidle
0.00 saturated 51298.65 busy 0.00 RS fetchable 200.00 runnable 300.00
Then Boinc should do the following math:
0.501165 * 0.999492 * 293767.52 = 147151.2083532263 seconds, worth of work to
fetch
Quick log of Boinc work fetches (no user interaction):
20/08/2010 18:26:12 | s...@home Beta Test | [work_fetch] request: 1895886.13
sec CPU (1895886.13 sec, 0.00) NVIDIA GPU (283333.40 sec, 0.00) ATI GPU
(344547.08 sec, 1.00)
20/08/2010 18:28:31 | s...@home Beta Test | [work_fetch] request: 1887455.83
sec CPU (1887455.83 sec, 0.00) NVIDIA GPU (173336.53 sec, 0.00) ATI GPU
(344829.56 sec, 1.00)
20/08/2010 18:29:44 | s...@home Beta Test | [work_fetch] request: 1887781.69
sec CPU (1887781.69 sec, 0.00) NVIDIA GPU (173469.36 sec, 0.00) ATI GPU
(229984.88 sec, 0.67)
20/08/2010 18:32:17 | s...@home | [work_fetch] request: 1879445.95 sec CPU
(1879445.95 sec, 5.96) NVIDIA GPU (62556.33 sec, 0.50) ATI GPU (0.00 sec, 0.00)
20/08/2010 18:32:55 | s...@home Beta Test | [work_fetch] request: 1818909.15
sec CPU (1818909.15 sec, 0.00) NVIDIA GPU (8101.11 sec, 0.00) ATI GPU
(345355.78 sec, 1.00)
20/08/2010 18:33:37 | s...@home Beta Test | [work_fetch] request: 1633914.20
sec CPU (1633914.20 sec, 0.00) NVIDIA GPU (2852.89 sec, 0.00) ATI GPU
(345439.49 sec, 1.00)
Here are the shortfalls for my Cuda card:
20/08/2010 18:29:54 | | [work_fetch] NVIDIA GPU: shortfall 128562.27 nidle
0.00 saturated 216287.76 busy 0.00 RS fetchable 0.00 runnable 300.00
20/08/2010 18:31:28 | | [work_fetch] NVIDIA GPU: shortfall 106284.59 nidle
0.00 saturated 238987.38 busy 0.00 RS fetchable 0.00 runnable 300.00
20/08/2010 18:33:17 | | [work_fetch] NVIDIA GPU: shortfall 2812.53 nidle 0.00
saturated 342086.84 busy 0.00 RS fetchable 0.00 runnable 300.00
20/08/2010 18:34:13 | | [work_fetch] NVIDIA GPU: shortfall 2940.19 nidle 0.00
saturated 341959.77 busy 0.00 RS fetchable 0.00 runnable 300.00
And here is the final work fetch log before sending this email:
20/08/2010 18:38:27 | | [work_fetch] ------- start work fetch state -------
20/08/2010 18:38:27 | | [work_fetch] target work buffer: 0.86 + 345600.00 sec
20/08/2010 18:38:27 | | [work_fetch] CPU: shortfall 1597484.03 nidle 0.00
saturated 72026.74 busy 0.00 RS fetchable 200.00 runnable 200.00
20/08/2010 18:38:27 | Collatz Conjecture | [work_fetch] CPU: fetch share 0.00
LTD 0.00 backoff dt 0.00 int 0.00 (comm deferred) (blocked by prefs)
20/08/2010 18:38:27 | s...@home | [work_fetch] CPU: fetch share 0.00 LTD
-67965.61 backoff dt 564.45 int 960.00
20/08/2010 18:38:27 | s...@home Beta Test | [work_fetch] CPU: fetch share 1.00
LTD 0.00 backoff dt 0.00 int 240.00
20/08/2010 18:38:27 | | [work_fetch] NVIDIA GPU: shortfall 3571.10 nidle 0.00
saturated 341324.09 busy 0.00 RS fetchable 100.00 runnable 300.00
20/08/2010 18:38:27 | Collatz Conjecture | [work_fetch] NVIDIA GPU: fetch share
0.00 LTD 0.00 backoff dt 0.00 int 0.00 (comm deferred) (blocked by prefs)
20/08/2010 18:38:27 | s...@home | [work_fetch] NVIDIA GPU: fetch share 1.00 LTD
-165336.84 backoff dt 0.00 int 480.00
20/08/2010 18:38:27 | s...@home Beta Test | [work_fetch] NVIDIA GPU: fetch
share 0.00 LTD 0.00 backoff dt 317.94 int 480.00
20/08/2010 18:38:27 | | [work_fetch] ATI GPU: shortfall 343582.67 nidle 0.00
saturated 2018.20 busy 0.00 RS fetchable 0.00 runnable 0.00
20/08/2010 18:38:27 | Collatz Conjecture | [work_fetch] ATI GPU: fetch share
0.00 LTD 0.00 backoff dt 0.00 int 0.00 (comm deferred)
20/08/2010 18:38:27 | s...@home | [work_fetch] ATI GPU: fetch share 0.00 LTD
-128509.35 backoff dt 457.58 int 960.00
20/08/2010 18:38:27 | s...@home Beta Test | [work_fetch] ATI GPU: fetch share
0.00 LTD 0.00 backoff dt 264.53 int 480.00
20/08/2010 18:38:27 | Collatz Conjecture | [work_fetch] overall LTD -8022.47
20/08/2010 18:38:27 | s...@home | [work_fetch] overall LTD -2900183.21
20/08/2010 18:38:27 | s...@home Beta Test | [work_fetch] overall LTD -1906833.34
20/08/2010 18:38:27 | | [work_fetch] ------- end work fetch state -------
I've also attached a copy of the log for
you, but as you can see from above, Boinc has requested and received far
more work for the Cuda card than the 147151.2083532263 seconds that it
should have done using the math above?
Am I getting confused about the math here, are the messages wrong or is Boinc
still requesting the full 4 day cache?
Regards
Ghost
From: Jamie Tiller
[mailto:[email protected]]
Sent: 11 August 2010 21:31
To: [email protected]
Cc: [email protected]; [email protected]
Subject: RE: [boinc_dev] Work Fetch Request Logic
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.
Work Fetch Log.rar
Description: Binary data
_______________________________________________ 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.
