The problem arises when there are jobs of projects
with widely differing resource shares,
and results in an overestimation of saturated time.
Old: at the start of simulation, call WORK_FETCH::compute_shares()
to get resources of runnable projects.
Use these throughout the simulation.
Problem: suppose you have 2 runnable projects;
P1 has large RS, P2 has small RS.
P1's jobs finish quickly.
P2's jobs then are running alone,
but their FLOPS is scaled (incorrectly) by P2's small RS.
Solution: recompute relative CPU resource share within the
simulation loop,
and compute it over the projects that have actives jobs
in the simulation.
svn path=/trunk/boinc/; revision=23162
values to 0/24. Default value is now 6 hours between notification reminders.
clientgui/
BOINCBaseFrame.cpp
BOINCDialupManager.cpp
BOINCTaskBar.cpp
DlgOptions.cpp
svn path=/trunk/boinc/; revision=23141
for the current theme. My commit on 3 Mar 2010 wasn't good enough
for High-Contrast themes.
clientgui/
BOINCBaseView.cpp
DlgEventLog.cpp
svn path=/trunk/boinc/; revision=23137
sort them by create time before appending to notice list.
This ensures that, in the Notices tab,
notices are ordered decreasing create time within an RSS feed
(though not necessarily across feeds)
svn path=/trunk/boinc/; revision=23134
is the 'no notice' notice and then we transition to a single notice
from another source.
clientgui/
NoticeListCtrl.cpp, .h
svn path=/trunk/boinc/; revision=23132
whether news items are exported as notices.
The creator of a news item is shown a "Don't export" or "Export"
button on the thread page.
By default, news items are exported.
svn path=/trunk/boinc/; revision=23119
trickle_credit: grants credit based on CPU time reported in msg
trickle_echo: echoes trickle-up as a trickle-down
svn path=/trunk/boinc/; revision=23118
- in friend request notification, link to user page
- in user page, show ID
- remove "Account data for " in page title
svn path=/trunk/boinc/; revision=23112
A task descriptor may contain <daemon>.
Daemons are started before regular tasks,
run concurrently with them, and are killed on exit.
svn path=/trunk/boinc/; revision=23101
When we first send a job, we pick an app version,
then call wu_is_infeasible_fast()
to see if the host is able to run the job with that app version.
In addition to checking disk space etc.
this calls wu_is_infeasible_custom() to do project-specific checks
(e.g. for SETI@home: don't use GPUs for VLAR jobs).
However, when we resend a job, we pick an app version
(possibly different from the original one)
and send the job without any checking.
So, for example, we might send a VLAR job to a GPU,
or send a job to a host with insufficient disk space
(because free space has changed since original send).
Solution: call wu_is_infeasible_fast() before resending a job,
and if it returns true, mark the job as done and don't resend it.
svn path=/trunk/boinc/; revision=23098
(since we may have been waiting for upload finish)
- client: fix crash: if remove an RSS feed, remove its active HTTP op if any.
svn path=/trunk/boinc/; revision=23097
check if we've been in the loop for 10 sec.
If so, break out of it and reschedule.
Avoid starving GUI RPCs and heartbeats.
svn path=/trunk/boinc/; revision=23094
Win: enumerate all descendants, and kill them all TerminateProcess().
Unix:
send the main process a SIGTERM.
Check once a sec for existence of descendants.
if none, done
If any still exist after 10 sec, kill all descendants
- wrapper fix bug in Win env var stuff
- scheduler: check for VBox version 3.2+ in app_plan()
svn path=/trunk/boinc/; revision=23085
- client: fix bug in "wait 30 sec after exclusive app exits" logic
- client: fix compile warning and possible bug in is_remote_desktop()
- win: remove wrappture_example from solution
(until Hubzereo guys get their win lib working)
svn path=/trunk/boinc/; revision=23077
David Anderson