Re: [boinc_dev] Initial scheduling checkin
Heard from Richard that a fix has now been found for this problem. Thanks for tracking it down: The cause has been found. In your client_state.xml file, you'll find a section like this: [code]time_stats on_frac0.998909/on_frac connected_frac1.00/connected_frac active_frac0.75/active_frac gpu_active_frac0.174423/gpu_active_frac last_update1288914349.413624/last_update /time_stats[/code] If you change that gpu_active_frac to 1.00, things will return to normal. That should be quicker than reverting to v6.10.58 Thanks/Ed On Mon, Nov 1, 2010 at 3:30 PM, David Anderson da...@ssl.berkeley.eduwrote: Please set work_fetch_debug and send a few hours of event log. -- David On 01-Nov-2010 11:50 AM, Ed A wrote: While 6.12.4 is a big improvement over 6.11.x and 6.12.2, there is still a large nagging problem that surfaced in 6.11.7 and is still unfixed. In order to maintain a consistent queue in GPU projects the Additional work buffer has to be continuously increased. The only way I've found to reset this is to reinstall 6.11.6 or earlier and then install 6.12.4 again. As an example on one machine my 12 hour Collatz queue is up to an Additional work buffer of 5.77 days and increasing at the rate of ~0.5 days/calendar day in order to maintain a constant level. Other GPU project queues act similarly but not necessarily at as fast a rate (may be related to queue size). CPU projects seem to be unaffected by this queue shrinkage. BTW, the GPU scheduling changes in 6.12.4 (non-FIFO) are a welcome improvement. Thanks/Ed On Mon, Nov 1, 2010 at 11:03 AM, David Anderson da...@ssl.berkeley.edu mailto:da...@ssl.berkeley.edu wrote: I want to get 6.12 out the door as soon as we're all happy w/ notices. -- David ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Initial scheduling checkin
I checked in a fix that isn't exactly either of these. -- David On 02-Nov-2010 7:05 AM, john.mcl...@sybase.com wrote: Yes, it does happen with 6.12. I believe what is happening is that a high priority task is first in priority, and a multi CPU task that takes all CPUs on the device is second in priority. There are several possible fixes: 1) Have the function that orders the tasks by priority order all of the tasks by sorting by the criteria needed to order the tasks. The function that picks the tasks to run would then skip over any tasks that use more resources than available. This would also fix RAM over usage and other resource allocation issues that are not just the count. This option also allows tasks to change what resources they need on the fly if we decide to do it (this should not be that hard to implement). 2) Have the function that orders the tasks by priority skip over tasks that use more resources than are available. Possibly slightly easier to implement in the short term, but probably less useful overall. jm7 David Anderson da...@ssl.berkel ey.edu To Sent by: boinc_dev@ssl.berkeley.edu boinc_dev-bounce cc s...@ssl.berkeley.ed u Subject Re: [boinc_dev] Initial scheduling checkin 11/01/2010 06:05 PM I checked in a fix for 1). Does 2) happen with 6.12? If not, let's just wait for 6.12. -- David On 01-Nov-2010 7:18 AM, Richard Haselgrove wrote: I agree with John - this is a major change, and will need extensive testing. David, may I ask what your current expectation is for the timeline for the new scheduler? Specifically, are you going to attempt to incorporate it into v6.12, or would it be better to get all the 'notices' angst out of the way via a public release (and debug if necessary after BETA testing byt the public at large) first, and then we can concentrate all resources on functionality? I'm concerned that there seem to be a couple of recently-reported issues which might slip through the cracks. 1) In v6.12.4, the thrashing of GPU tasks into and out of GPU memory, because there seems to be no 'Task Switch Interval' inhibition on the new GPU scheduling by debt. 2) In v6.10.58, the idle CPUs apparently caused by the scheduler incorrectly handling the triple mixture of High Priority CPU / Multithread / ordinary priority single CPU tasks. (from http://boinc.berkeley.edu/dev/forum_thread.php?id=6138) If the new scheduler is going to be put into v6.12 (which will inevitably delay that release a bit), could those fixes (when ready) be backported into v6.10, please? Or if the new scheduler has to wait for v6.14, perhaps we should concentrate on getting v6.12 finished first? This needs to be tested thoroughly with some very long term simulations involving several years of simulation time. Anything that involves the concept of recent for work fetch will break resource share over the long term when used in conjunction with CPDN. jm7 When replying, please edit your Subject line so it is more specific than Re: Contents of boinc_cvs digest... Today's Topics: 1. r22608 - in trunk/boinc: . api client lib sched (boinc...@ssl.berkeley.edu) -- Message: 1 Date: Fri, 29 Oct 2010 16:41:35 -0700 From: boinc...@ssl.berkeley.edu Subject: [boinc_cvs] r22608 - in trunk/boinc: . api client lib sched To: boinc_...@ssl.berkeley.edu Message-ID:201010292341.o9tnfzuh013...@mail.ssl.berkeley.edu Content-Type: text/plain; charset=UTF-8 Author: davea Date: 2010-10-29 16:41:34 -0700 (Fri, 29 Oct 2010) New Revision: 22608 Modified: trunk/boinc/api/boinc_api.cpp trunk/boinc/checkin_notes trunk/boinc/client/client_types.cpp trunk/boinc/client/cpu_sched.cpp trunk/boinc/client/net_stats.cpp trunk/boinc/client/work_fetch.h trunk/boinc/lib/util.cpp trunk/boinc/lib/util.h trunk/boinc/sched/credit.cpp trunk/boinc/sched/update_stats.cpp Log: - client: small initial checkin for new scheduling system. Keep track of per-project recent estimated credit Modified: trunk/boinc/api/boinc_api.cpp === --- trunk/boinc/api/boinc_api.cpp 2010-10-29 18:58:26 UTC (rev 22607) +++ trunk/boinc/api/boinc_api.cpp 2010-10-29 23:41:34 UTC (rev 22608) @@ -835,9 +835,9 @@ #else strcpy(abspath, path); #endif -argv[0] = GRAPHICS_APP_FILENAME; +argv[0] = (char*)GRAPHICS_APP_FILENAME; if (fullscreen
Re: [boinc_dev] Initial scheduling checkin
Yes, it does happen with 6.12. I believe what is happening is that a high priority task is first in priority, and a multi CPU task that takes all CPUs on the device is second in priority. There are several possible fixes: 1) Have the function that orders the tasks by priority order all of the tasks by sorting by the criteria needed to order the tasks. The function that picks the tasks to run would then skip over any tasks that use more resources than available. This would also fix RAM over usage and other resource allocation issues that are not just the count. This option also allows tasks to change what resources they need on the fly if we decide to do it (this should not be that hard to implement). 2) Have the function that orders the tasks by priority skip over tasks that use more resources than are available. Possibly slightly easier to implement in the short term, but probably less useful overall. jm7 David Anderson da...@ssl.berkel ey.eduTo Sent by: boinc_dev@ssl.berkeley.edu boinc_dev-bounce cc s...@ssl.berkeley.ed uSubject Re: [boinc_dev] Initial scheduling checkin 11/01/2010 06:05 PM I checked in a fix for 1). Does 2) happen with 6.12? If not, let's just wait for 6.12. -- David On 01-Nov-2010 7:18 AM, Richard Haselgrove wrote: I agree with John - this is a major change, and will need extensive testing. David, may I ask what your current expectation is for the timeline for the new scheduler? Specifically, are you going to attempt to incorporate it into v6.12, or would it be better to get all the 'notices' angst out of the way via a public release (and debug if necessary after BETA testing byt the public at large) first, and then we can concentrate all resources on functionality? I'm concerned that there seem to be a couple of recently-reported issues which might slip through the cracks. 1) In v6.12.4, the thrashing of GPU tasks into and out of GPU memory, because there seems to be no 'Task Switch Interval' inhibition on the new GPU scheduling by debt. 2) In v6.10.58, the idle CPUs apparently caused by the scheduler incorrectly handling the triple mixture of High Priority CPU / Multithread / ordinary priority single CPU tasks. (from http://boinc.berkeley.edu/dev/forum_thread.php?id=6138) If the new scheduler is going to be put into v6.12 (which will inevitably delay that release a bit), could those fixes (when ready) be backported into v6.10, please? Or if the new scheduler has to wait for v6.14, perhaps we should concentrate on getting v6.12 finished first? This needs to be tested thoroughly with some very long term simulations involving several years of simulation time. Anything that involves the concept of recent for work fetch will break resource share over the long term when used in conjunction with CPDN. jm7 When replying, please edit your Subject line so it is more specific than Re: Contents of boinc_cvs digest... Today's Topics: 1. r22608 - in trunk/boinc: . api client lib sched (boinc...@ssl.berkeley.edu) -- Message: 1 Date: Fri, 29 Oct 2010 16:41:35 -0700 From: boinc...@ssl.berkeley.edu Subject: [boinc_cvs] r22608 - in trunk/boinc: . api client lib sched To: boinc_...@ssl.berkeley.edu Message-ID:201010292341.o9tnfzuh013...@mail.ssl.berkeley.edu Content-Type: text/plain; charset=UTF-8 Author: davea Date: 2010-10-29 16:41:34 -0700 (Fri, 29 Oct 2010) New Revision: 22608 Modified: trunk/boinc/api/boinc_api.cpp trunk/boinc/checkin_notes trunk/boinc/client/client_types.cpp trunk/boinc/client/cpu_sched.cpp trunk/boinc/client/net_stats.cpp trunk/boinc/client/work_fetch.h trunk/boinc/lib/util.cpp trunk/boinc/lib/util.h trunk/boinc/sched/credit.cpp trunk/boinc/sched/update_stats.cpp Log: - client: small initial checkin for new scheduling system. Keep track of per-project recent estimated
Re: [boinc_dev] Initial scheduling checkin
Yes, 2) is just (today + yesterday + ...??) happening on my machine with 6.12.4 (http://boinc.berkeley.edu/dev/forum_thread.php?id=6142nowrap=true#35511). I've already set some additional flags at the morning, yet to set work_fetch_debug. (Tomorrow.) Peter Slacik Dňa 01.11.2010 23:05, David Anderson wrote / napísal(a): I checked in a fix for 1). Does 2) happen with 6.12? If not, let's just wait for 6.12. -- David On 01-Nov-2010 7:18 AM, Richard Haselgrove wrote: [...] I'm concerned that there seem to be a couple of recently-reported issues which might slip through the cracks. 1) In v6.12.4, the thrashing of GPU tasks into and out of GPU memory, because there seems to be no 'Task Switch Interval' inhibition on the new GPU scheduling by debt. 2) In v6.10.58, the idle CPUs apparently caused by the scheduler incorrectly handling the triple mixture of High Priority CPU / Multithread / ordinary priority single CPU tasks. (from http://boinc.berkeley.edu/dev/forum_thread.php?id=6138) ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Initial scheduling checkin (was: boinc_cvs Digest, Vol 71, Issue 48)
I agree with John - this is a major change, and will need extensive testing.
David, may I ask what your current expectation is for the timeline for the
new scheduler? Specifically, are you going to attempt to incorporate it into
v6.12, or would it be better to get all the 'notices' angst out of the way
via a public release (and debug if necessary after BETA testing byt the
public at large) first, and then we can concentrate all resources on
functionality?
I'm concerned that there seem to be a couple of recently-reported issues
which might slip through the cracks.
1) In v6.12.4, the thrashing of GPU tasks into and out of GPU memory,
because there seems to be no 'Task Switch Interval' inhibition on the new
GPU scheduling by debt.
2) In v6.10.58, the idle CPUs apparently caused by the scheduler incorrectly
handling the triple mixture of High Priority CPU / Multithread / ordinary
priority single CPU tasks.
(from http://boinc.berkeley.edu/dev/forum_thread.php?id=6138)
If the new scheduler is going to be put into v6.12 (which will inevitably
delay that release a bit), could those fixes (when ready) be backported into
v6.10, please?
Or if the new scheduler has to wait for v6.14, perhaps we should concentrate
on getting v6.12 finished first?
This needs to be tested thoroughly with some very long term simulations
involving several years of simulation time. Anything that involves the
concept of recent for work fetch will break resource share over the long
term when used in conjunction with CPDN.
jm7
When replying, please edit your Subject line so it is more specific
than Re: Contents of boinc_cvs digest...
Today's Topics:
1. r22608 - in trunk/boinc: . api client lib sched
(boinc...@ssl.berkeley.edu)
--
Message: 1
Date: Fri, 29 Oct 2010 16:41:35 -0700
From: boinc...@ssl.berkeley.edu
Subject: [boinc_cvs] r22608 - in trunk/boinc: . api client lib sched
To: boinc_...@ssl.berkeley.edu
Message-ID: 201010292341.o9tnfzuh013...@mail.ssl.berkeley.edu
Content-Type: text/plain; charset=UTF-8
Author: davea
Date: 2010-10-29 16:41:34 -0700 (Fri, 29 Oct 2010)
New Revision: 22608
Modified:
trunk/boinc/api/boinc_api.cpp
trunk/boinc/checkin_notes
trunk/boinc/client/client_types.cpp
trunk/boinc/client/cpu_sched.cpp
trunk/boinc/client/net_stats.cpp
trunk/boinc/client/work_fetch.h
trunk/boinc/lib/util.cpp
trunk/boinc/lib/util.h
trunk/boinc/sched/credit.cpp
trunk/boinc/sched/update_stats.cpp
Log:
- client: small initial checkin for new scheduling system.
Keep track of per-project recent estimated credit
Modified: trunk/boinc/api/boinc_api.cpp
===
--- trunk/boinc/api/boinc_api.cpp 2010-10-29 18:58:26 UTC (rev
22607)
+++ trunk/boinc/api/boinc_api.cpp 2010-10-29 23:41:34 UTC (rev
22608)
@@ -835,9 +835,9 @@
#else
strcpy(abspath, path);
#endif
-argv[0] = GRAPHICS_APP_FILENAME;
+argv[0] = (char*)GRAPHICS_APP_FILENAME;
if (fullscreen) {
-argv[1] = --fullscreen;
+argv[1] = (char*)--fullscreen;
argv[2] = 0;
argc = 2;
} else {
Modified: trunk/boinc/checkin_notes
===
--- trunk/boinc/checkin_notes2010-10-29 18:58:26 UTC (rev 22607)
+++ trunk/boinc/checkin_notes2010-10-29 23:41:34 UTC (rev 22608)
@@ -7660,3 +7660,20 @@
client_msgs.cpp
clientgui/
NoticeListCtrl.cpp
+
+David 29 Oct 2010
+- client: small initial checkin for new scheduling system.
+Keep track of per-project recent estimated credit
+
+api/
+boinc_api.cpp
+client/
+client_types.cpp
+cpu_sched.cpp
+net_stats.cpp
+work_fetch.h
+lib/
+util.cpp,h
+sched/
+credit.cpp
+update_stats.cpp
Modified: trunk/boinc/client/client_types.cpp
===
--- trunk/boinc/client/client_types.cpp 2010-10-29 18:58:26 UTC
(rev 22607)
+++ trunk/boinc/client/client_types.cpp 2010-10-29 23:41:34 UTC
(rev 22608)
@@ -202,6 +202,8 @@
if (parse_bool(buf, dont_request_more_work,
dont_request_more_work)) continue;
if (parse_bool(buf, detach_when_done, detach_when_done))
continue;
if (parse_bool(buf, ended, ended)) continue;
+if (parse_double(buf, rec, pwf.rec)) continue;
+if (parse_double(buf, rec_time, pwf.rec_time)) continue;
if (parse_double(buf, short_term_debt,
cpu_pwf.short_term_debt)) continue;
if (parse_double(buf, long_term_debt, cpu_pwf.long_term_debt))
continue;
if (parse_double(buf, cpu_backoff_interval,
cpu_pwf.backoff_interval)) continue;
@@
Re: [boinc_dev] Initial scheduling checkin
While 6.12.4 is a big improvement over 6.11.x and 6.12.2, there is still a large nagging problem that surfaced in 6.11.7 and is still unfixed. In order to maintain a consistent queue in GPU projects the Additional work buffer has to be continuously increased. The only way I've found to reset this is to reinstall 6.11.6 or earlier and then install 6.12.4 again. As an example on one machine my 12 hour Collatz queue is up to an Additional work buffer of 5.77 days and increasing at the rate of ~0.5 days/calendar day in order to maintain a constant level. Other GPU project queues act similarly but not necessarily at as fast a rate (may be related to queue size). CPU projects seem to be unaffected by this queue shrinkage. BTW, the GPU scheduling changes in 6.12.4 (non-FIFO) are a welcome improvement. Thanks/Ed On Mon, Nov 1, 2010 at 11:03 AM, David Anderson da...@ssl.berkeley.eduwrote: I want to get 6.12 out the door as soon as we're all happy w/ notices. -- David ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Initial scheduling checkin
Please set work_fetch_debug and send a few hours of event log. -- David On 01-Nov-2010 11:50 AM, Ed A wrote: While 6.12.4 is a big improvement over 6.11.x and 6.12.2, there is still a large nagging problem that surfaced in 6.11.7 and is still unfixed. In order to maintain a consistent queue in GPU projects the Additional work buffer has to be continuously increased. The only way I've found to reset this is to reinstall 6.11.6 or earlier and then install 6.12.4 again. As an example on one machine my 12 hour Collatz queue is up to an Additional work buffer of 5.77 days and increasing at the rate of ~0.5 days/calendar day in order to maintain a constant level. Other GPU project queues act similarly but not necessarily at as fast a rate (may be related to queue size). CPU projects seem to be unaffected by this queue shrinkage. BTW, the GPU scheduling changes in 6.12.4 (non-FIFO) are a welcome improvement. Thanks/Ed On Mon, Nov 1, 2010 at 11:03 AM, David Anderson da...@ssl.berkeley.edu mailto:da...@ssl.berkeley.edu wrote: I want to get 6.12 out the door as soon as we're all happy w/ notices. -- David ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Initial scheduling checkin
I checked in a fix for 1).
Does 2) happen with 6.12?
If not, let's just wait for 6.12.
-- David
On 01-Nov-2010 7:18 AM, Richard Haselgrove wrote:
I agree with John - this is a major change, and will need extensive testing.
David, may I ask what your current expectation is for the timeline for the
new scheduler? Specifically, are you going to attempt to incorporate it into
v6.12, or would it be better to get all the 'notices' angst out of the way
via a public release (and debug if necessary after BETA testing byt the
public at large) first, and then we can concentrate all resources on
functionality?
I'm concerned that there seem to be a couple of recently-reported issues
which might slip through the cracks.
1) In v6.12.4, the thrashing of GPU tasks into and out of GPU memory,
because there seems to be no 'Task Switch Interval' inhibition on the new
GPU scheduling by debt.
2) In v6.10.58, the idle CPUs apparently caused by the scheduler incorrectly
handling the triple mixture of High Priority CPU / Multithread / ordinary
priority single CPU tasks.
(from http://boinc.berkeley.edu/dev/forum_thread.php?id=6138)
If the new scheduler is going to be put into v6.12 (which will inevitably
delay that release a bit), could those fixes (when ready) be backported into
v6.10, please?
Or if the new scheduler has to wait for v6.14, perhaps we should concentrate
on getting v6.12 finished first?
This needs to be tested thoroughly with some very long term simulations
involving several years of simulation time. Anything that involves the
concept of recent for work fetch will break resource share over the long
term when used in conjunction with CPDN.
jm7
When replying, please edit your Subject line so it is more specific
than Re: Contents of boinc_cvs digest...
Today's Topics:
1. r22608 - in trunk/boinc: . api client lib sched
(boinc...@ssl.berkeley.edu)
--
Message: 1
Date: Fri, 29 Oct 2010 16:41:35 -0700
From: boinc...@ssl.berkeley.edu
Subject: [boinc_cvs] r22608 - in trunk/boinc: . api client lib sched
To: boinc_...@ssl.berkeley.edu
Message-ID:201010292341.o9tnfzuh013...@mail.ssl.berkeley.edu
Content-Type: text/plain; charset=UTF-8
Author: davea
Date: 2010-10-29 16:41:34 -0700 (Fri, 29 Oct 2010)
New Revision: 22608
Modified:
trunk/boinc/api/boinc_api.cpp
trunk/boinc/checkin_notes
trunk/boinc/client/client_types.cpp
trunk/boinc/client/cpu_sched.cpp
trunk/boinc/client/net_stats.cpp
trunk/boinc/client/work_fetch.h
trunk/boinc/lib/util.cpp
trunk/boinc/lib/util.h
trunk/boinc/sched/credit.cpp
trunk/boinc/sched/update_stats.cpp
Log:
- client: small initial checkin for new scheduling system.
Keep track of per-project recent estimated credit
Modified: trunk/boinc/api/boinc_api.cpp
===
--- trunk/boinc/api/boinc_api.cpp 2010-10-29 18:58:26 UTC (rev
22607)
+++ trunk/boinc/api/boinc_api.cpp 2010-10-29 23:41:34 UTC (rev
22608)
@@ -835,9 +835,9 @@
#else
strcpy(abspath, path);
#endif
-argv[0] = GRAPHICS_APP_FILENAME;
+argv[0] = (char*)GRAPHICS_APP_FILENAME;
if (fullscreen) {
-argv[1] = --fullscreen;
+argv[1] = (char*)--fullscreen;
argv[2] = 0;
argc = 2;
} else {
Modified: trunk/boinc/checkin_notes
===
--- trunk/boinc/checkin_notes2010-10-29 18:58:26 UTC (rev 22607)
+++ trunk/boinc/checkin_notes2010-10-29 23:41:34 UTC (rev 22608)
@@ -7660,3 +7660,20 @@
client_msgs.cpp
clientgui/
NoticeListCtrl.cpp
+
+David 29 Oct 2010
+- client: small initial checkin for new scheduling system.
+Keep track of per-project recent estimated credit
+
+api/
+boinc_api.cpp
+client/
+client_types.cpp
+cpu_sched.cpp
+net_stats.cpp
+work_fetch.h
+lib/
+util.cpp,h
+sched/
+credit.cpp
+update_stats.cpp
Modified: trunk/boinc/client/client_types.cpp
===
--- trunk/boinc/client/client_types.cpp 2010-10-29 18:58:26 UTC
(rev 22607)
+++ trunk/boinc/client/client_types.cpp 2010-10-29 23:41:34 UTC
(rev 22608)
@@ -202,6 +202,8 @@
if (parse_bool(buf, dont_request_more_work,
dont_request_more_work)) continue;
if (parse_bool(buf, detach_when_done, detach_when_done))
continue;
if (parse_bool(buf, ended, ended)) continue;
+if (parse_double(buf, rec, pwf.rec)) continue;
+if (parse_double(buf, rec_time, pwf.rec_time)) continue;
if (parse_double(buf, short_term_debt,
cpu_pwf.short_term_debt)) continue;
Re: [boinc_dev] Initial scheduling checkin
Neither of the two users who were making a fuss about (2) on the BOINC
message boards last week have posted since we started to get an idea what
the problem was. I think Jord has at least one email address, but I don't.
If I can find enough working servers to over-fill my cache to the 'high
priority' level tomorrow (I can probably fudge it by falsifying on_frac),
I'll try to reproduce and log - and if I can make it happen, I'll drop it in
the simulator too.
I checked in a fix for 1).
Does 2) happen with 6.12?
If not, let's just wait for 6.12.
-- David
On 01-Nov-2010 7:18 AM, Richard Haselgrove wrote:
I agree with John - this is a major change, and will need extensive
testing.
David, may I ask what your current expectation is for the timeline for
the
new scheduler? Specifically, are you going to attempt to incorporate it
into
v6.12, or would it be better to get all the 'notices' angst out of the
way
via a public release (and debug if necessary after BETA testing byt the
public at large) first, and then we can concentrate all resources on
functionality?
I'm concerned that there seem to be a couple of recently-reported issues
which might slip through the cracks.
1) In v6.12.4, the thrashing of GPU tasks into and out of GPU memory,
because there seems to be no 'Task Switch Interval' inhibition on the new
GPU scheduling by debt.
2) In v6.10.58, the idle CPUs apparently caused by the scheduler
incorrectly
handling the triple mixture of High Priority CPU / Multithread / ordinary
priority single CPU tasks.
(from http://boinc.berkeley.edu/dev/forum_thread.php?id=6138)
If the new scheduler is going to be put into v6.12 (which will inevitably
delay that release a bit), could those fixes (when ready) be backported
into
v6.10, please?
Or if the new scheduler has to wait for v6.14, perhaps we should
concentrate
on getting v6.12 finished first?
This needs to be tested thoroughly with some very long term simulations
involving several years of simulation time. Anything that involves the
concept of recent for work fetch will break resource share over the long
term when used in conjunction with CPDN.
jm7
When replying, please edit your Subject line so it is more specific
than Re: Contents of boinc_cvs digest...
Today's Topics:
1. r22608 - in trunk/boinc: . api client lib sched
(boinc...@ssl.berkeley.edu)
--
Message: 1
Date: Fri, 29 Oct 2010 16:41:35 -0700
From: boinc...@ssl.berkeley.edu
Subject: [boinc_cvs] r22608 - in trunk/boinc: . api client lib sched
To: boinc_...@ssl.berkeley.edu
Message-ID:201010292341.o9tnfzuh013...@mail.ssl.berkeley.edu
Content-Type: text/plain; charset=UTF-8
Author: davea
Date: 2010-10-29 16:41:34 -0700 (Fri, 29 Oct 2010)
New Revision: 22608
Modified:
trunk/boinc/api/boinc_api.cpp
trunk/boinc/checkin_notes
trunk/boinc/client/client_types.cpp
trunk/boinc/client/cpu_sched.cpp
trunk/boinc/client/net_stats.cpp
trunk/boinc/client/work_fetch.h
trunk/boinc/lib/util.cpp
trunk/boinc/lib/util.h
trunk/boinc/sched/credit.cpp
trunk/boinc/sched/update_stats.cpp
Log:
- client: small initial checkin for new scheduling system.
Keep track of per-project recent estimated credit
Modified: trunk/boinc/api/boinc_api.cpp
===
--- trunk/boinc/api/boinc_api.cpp 2010-10-29 18:58:26 UTC (rev
22607)
+++ trunk/boinc/api/boinc_api.cpp 2010-10-29 23:41:34 UTC (rev
22608)
@@ -835,9 +835,9 @@
#else
strcpy(abspath, path);
#endif
-argv[0] = GRAPHICS_APP_FILENAME;
+argv[0] = (char*)GRAPHICS_APP_FILENAME;
if (fullscreen) {
-argv[1] = --fullscreen;
+argv[1] = (char*)--fullscreen;
argv[2] = 0;
argc = 2;
} else {
Modified: trunk/boinc/checkin_notes
===
--- trunk/boinc/checkin_notes2010-10-29 18:58:26 UTC (rev 22607)
+++ trunk/boinc/checkin_notes2010-10-29 23:41:34 UTC (rev 22608)
@@ -7660,3 +7660,20 @@
client_msgs.cpp
clientgui/
NoticeListCtrl.cpp
+
+David 29 Oct 2010
+- client: small initial checkin for new scheduling system.
+Keep track of per-project recent estimated credit
+
+api/
+boinc_api.cpp
+client/
+client_types.cpp
+cpu_sched.cpp
+net_stats.cpp
+work_fetch.h
+lib/
+util.cpp,h
+sched/
+credit.cpp
+update_stats.cpp
Modified: trunk/boinc/client/client_types.cpp
===
--- trunk/boinc/client/client_types.cpp 2010-10-29 18:58:26 UTC
(rev 22607)
+++ trunk/boinc/client/client_types.cpp
