10000*major + 100*minor + release,
rather than 100*major + minor.
Sometimes you need release-level resolution.
This affects:
- app_version.min_core_version
- config: min_core_client_version_announced
- config: min_core_client_version
Projects using these must multiply them by 100.
svn path=/trunk/boinc/; revision=20149
if project has crazy DCF, don't automatically request 1 sec;
only request work if there's a shortfall.
- intermediate checkin for notices stuff
svn path=/trunk/boinc/; revision=20145
sends the first rather than last 64KB of stderr to server.
This doesn't belong here; this choice should come from the server.
I may take this out later.
- user web: when add a private message, always add a notification
svn path=/trunk/boinc/; revision=20141
deletion' pass to 50000 (can be changed with -delete_antiques_limit).
Previously large number of antiques led to not deleting any at all.
- Allow to change the interval between passes with -delete_antiques_interval.
svn path=/trunk/boinc/; revision=20138
to restart app for 10 minutes.
Hopefully what will happen is:
- another instance of app is running in slot dir
(shouldn't happen, but sometimes does)
- that app will eventually finish, and will write
a checkpoint file saying so.
It will call boinc_finish(0), but the client won't notice
that it has exited.
- the next time the client starts the app,
it will acquire lock, see that it's done,
and call boinc_finish(0).
This time the client will notice,
and the job will be reported as correct.
The downside to all this is that the client won't know
that the CPU is in use, and will schedule NCPUS jobs.
svn path=/trunk/boinc/; revision=20128
- a project overestimates job FLOP counts
- the client starts jobs in EDF mode
- as job progresses and fraction done increases,
its completion time estimate decreases until
it's no longer a deadline miss.
- job gets preempted by other job from that project;
you end up with lots of partly completed jobs.
Solution (I hope): if an app version has running jobs,
compute a "temp DCF" for the app version,
which is the min of dynamic/static estimates for its jobs.
Apply this scaling factor to completion time estimates
for unstarted jobs in RR simulation
- client: the estimation of remaining time of running jobs was wrong
(how did this bug survive so long?)
svn path=/trunk/boinc/; revision=20077
- remove obsolete and buggy code from transitioner (create_result() in backend_lib)
- account for 'mixed' scheduling in explain_to_user() in sched_send.cpp
- finish transition to configurable patterns for distinguishing files reported by the client
in the Einstein@home-specific part of send_work_locality in sched_locality
(removed previous hardcoded strcmps)
svn path=/trunk/boinc/; revision=20074
- lib: remove memset from notice constructor, bad things can happen
when you null out a std::string structure.
lib/
gui_rpc_client.h
gui_rpc_client_ops.cpp
notice.cpp, .h
svn path=/trunk/boinc/; revision=20065
This is like boinc_init() but for multithread apps.
Unlike boinc_init(), it suspends/resumes all threads in the app,
not just one.
In Unix, this is done by forking,
and having the parent process handle suspend/resume messages
and suspend/resume the child using signals
On Win, there's some nasty code that enumerates all
threads in the whole system, and suspends/resumes
those in a particular process.
svn path=/trunk/boinc/; revision=20054
will have enough jobs to use its share of resource instances.
This avoids situations where e.g. on a 2-CPU system
a project has 75% resource share and 1 CPU job,
and its STD increases without bound.
Did a general cleanup of the logic for computing
work request sizes (seconds and instances).
svn path=/trunk/boinc/; revision=20036
The RSS feed part of it is mostly working.
- client: fix bug in XML_PARSER (tags with attributes weren't
parsed correctly if no attribute buffer supplied)
svn path=/trunk/boinc/; revision=20026
class, it is not owned by any frame, it is modeless.
NOTE: Need to consult with Charlie about how best to register modeless
dialogs for RPC updates. They are not owned by a frame and should
be capable of being displayed or view from any frame. i.e.
SwitchActiveGUI() should not have any effect on them.
- MGR: Display a window title with the async waiting dialog.
clientgui/
AdvancedFrame.cpp, .h
AsyncRPC.cpp
BOINCBaseFrame.cpp
BOINCGUIApp.cpp, .h
DlgEventLog.cpp
svn path=/trunk/boinc/; revision=20014
the main manager window to move to the top of the z-order even
while the dialog is up.
clientgui/
DlgEventLog.cpp, .h
svn path=/trunk/boinc/; revision=20010
and avg_ncpus for GPU apps.
App versions are now characterized by two parameters
(we assume that the app uses either the CPU or the GPU
at a given time, but not both):
- the fraction of FLOPs performed on the CPU
- when the app is using the GPU, the fraction of peak FLOPS
that it gets.
We then run the numbers to get the total FLOPS and avg_ncpus.
svn path=/trunk/boinc/; revision=19977
- MGR: When a notification is clicked open up the GUI
and switch to the notification tab in the advanced
view.
- MGR: Reorder tabs
- MGR: Review messages tab
- MGR: cleanup code in various places
clientgui/
AdvancedFrame.cpp, .h
BOINCBaseFrame.cpp, .h
BOINCGUIApp.cpp, .h
BOINCTaskBar.cpp, .h
DlgEventLog.cpp, .h (Added)
Events.h
MainDocument.cpp, .h
ViewNews.cpp, .h (Deleted)
ViewNotifications.cpp, .h (Added)
win_build/
boincmgr.vcproj
svn path=/trunk/boinc/; revision=19976
Old: in a flat file (html/project/project_news.inc)
New: in a forum (called "News" by default)
The script html/ops/news_convert.php copies news from
old to new format.
You'll also need to edit your index.php and use
"show_news(0, 5)" to show news.
- web: added a "message of the day" mechanism.
Edit html/user/motd.php to show a message.
This will be shown as the first news item,
but it's not archived (i.e., it's not a forum post)
svn path=/trunk/boinc/; revision=19949
the BOINC stylesheet (main.css) was included.
This is no good if we're exporting the HTML.
Add an option to generate generic HTML.
- web: add options to the forum RSS feed:
1) threads_only: just show threads (i.e. 1st post in each thread)
2) truncate: truncate posts to 256 chars.
If this is not set, convert post from BBcode to generic HTML,
and put this (XML-encoded) in item.description
This is preparation for using the forum code for project news,
and for displaying forum RSS feeds in the manager.
svn path=/trunk/boinc/; revision=19915
This exits the app with status zero and no finish file,
so the client will restart it.
It creates a file "temporary_exit" containing dt.
The (new) client reads this file and will postpone
scheduling the job again for dt seconds.
Old clients will treat it as a premature exit,
and potentially try to reschedule the job immediately.
This function is intended for GPU applications that
fail to allocate GPU RAM,
presumably because a non-GPU application has it allocated.
We don't want the job to fail,
and we want to wait for a while before trying the allocation again.
svn path=/trunk/boinc/; revision=19879
RAM to run job, but when we actually run the job
not enough GPU RAM is free, so the application fails.
This can cause a large number of jobs to fail.
Solution:
- app_plan() can specify the GPU RAM requirements of an app version.
This is passed to the client in a new field
<gpu_ram> of the <app_version> element.
- prior to starting or restarting a GPU app, the client
checks the amount of free RAM on the particular GPU.
If it's not enough for the app version,
the client doesn't start it,
and arranges for the scheduler to ignore it for 5 minutes
(by which point there might be more free GPU RAM)
Notes:
1) this change will have effect only when
both client and scheduler are updated.
2) the check is done in enforce_schedule(),
rather than schedule_cpus(),
because only at that point
have we assigned a specific GPU to the job.
3) there's another case to deal with:
a GPU app's malloc of GPU RAM fails in the middle of the job.
Currently the job fails.
I plan to add an API call boinc_temporary_exit(x) so
that the job can exit and potentially restart in x seconds.
(In principle this mechanism is sufficient for all cases,
but it could lead to a lot of starting/exiting,
so the current change is worthwhile).
svn path=/trunk/boinc/; revision=19864
can increase or decrease at N times real time.
My checkin of 7 Dec reflects this by changing
the STD limits to +- N*MAX_STD.
This looks like a bug to users.
Instead, scale that rate of STD change by 1/N,
and keep the old limits of +- MAX_STD
svn path=/trunk/boinc/; revision=19851
Old: if a project has RR sim deadline misses,
select jobs to run high-priority on the basis of:
1) deadline (earliest first)
2) estimated time to completion (least first)
This ignores whether jobs missed their deadline in RR sim,
so it may choose to run a job that's actually in no
danger of missing its deadline over one that is.
New: choose only jobs that miss their deadline in RR sim
svn path=/trunk/boinc/; revision=19826
Let them float around with other projects.
Fixes problem where, when a project finishes its last job
and has a negative STD, it gets an unfair increment
by being set to zero.
svn path=/trunk/boinc/; revision=19804
Source of proxy info (descending priority)
- GUI RPC (Manager or boinccmd)
This and only this is saved in state file.
If neither HTTP nor SOCKS server name present,
this is viewed as not present
- environment vars
- cc_config.xml
Show sources of proxy info in message log.
If one is present but overridden, show a message to that effect.
This fixes a bug where someone had a proxy info env var and
forgot about it.
They got an erroneous message saying no proxy was being used.
svn path=/trunk/boinc/; revision=19785
It computed an "overall STD" as the sum of CPU and coprocs,
weighted by the coproc's speed, as we do for LTD.
This was the wrong idea; in the presence of GPUs,
STDs quickly get pushed to +- 1 day and are truncated there.
New scheme: STD is maintained per (resource type, project).
This fixes the above problem,
and it opens to door to round-robin scheduling of GPUs.
- client: the calculation of "anticipated debt" was scaling
by relative resource share.
This wasn't correct, seems to me.
- client: rename "debt" to "long_term_debt" in a few places
(but not in the client state file, for compatibility)
svn path=/trunk/boinc/; revision=19777
only if the offset is positive.
- client: some cmdline args set members of config.
However, config was being cleared after cmdline args were parsed,
so these args had no effect.
Instead, clear config before parsing cmdline
svn path=/trunk/boinc/; revision=19776
Old: it's based entirely on CPU time.
So a GPU project, whose app uses only a fraction
of a CPU, accrues positive debt.
This is OK if the project has only GPU apps,
since STD is not (currently) used for GPU scheduling.
But some projects have both CPU and GPU apps.
New: STD is based on total processing.
It has terms for each resource type.
The notion of "runnable resource share" is specific to a type.
Note: the notion of "resource share fraction" appears in
a couple of other places:
- it's passed to apps in app_init_data.xml
- it's passed in scheduler requests.
It should be broken down by resource type in these cases too.
Note to self: do this later.
svn path=/trunk/boinc/; revision=19762
you have highlighted a project you are already attached too, should
not cause the 'you are already attached to project' dialog to be
displayed. This also appears to have fixed the random page being
displayed when the dialog has been dismissed.
clientgui/
ProjectInfoPage.cpp
svn path=/trunk/boinc/; revision=19736
This tells you what's running, not why
- client: add <std_debug> log flag; changes in STD
The above are to let you log just stuff relevant to debt.
Right now I'm not sure why we need STD at all.
svn path=/trunk/boinc/; revision=19726
suppose. Increment the index before use instead of just adding
1. Next iteration through the main loop will then pick-up
new parameter instead of the value for the previously
processed command. Parameter parsing 101.
client/
boinc_log.cpp
svn path=/trunk/boinc/; revision=19700
date and time information instead of RFCXXXX.
- log: Remove the ending newline character from the messages before
looking for any newline characters which would appear in
multi-line messages like those from http_debug.
client/
boinc_log.cpp
svn path=/trunk/boinc/; revision=19695
the message log cache of the client. Useful for debugging debt
related issues using Excel or various databases.
client/
boinc_cmd.cpp
boinc_log.cpp
win_build/
boinclog.vcproj (added)
svn path=/trunk/boinc/; revision=19686
Windows. The goal is to completely automate the build process
by creating a self contained environment for the scripts to
execute under. When completed it'll be able to do the following:
* Increment version information
* Build client software using installed version of VS.
* Validate symbol files for specific components.
* Add source file information to symbol files. (This will allow
VS to automatically download the source file from SVN while
single-stepping through the code on a clean machine)
* Code sign executables
* Build installer
* Code sign installer
* Upload updated symbol files and and setup packages
When building interactively:
* Automatically update the DLLs BOINC and BOINCMgr depend on
when they have been updated in the source tree.
* Fix-up BOINC project files when new branches are created
* Fix-up project files for components BOINC depends on when
new versions are released.
/
version.log (added)
win_build/
buildenv.cmd (added)
boinc_post_bld_rules.cmd
boinc_cli.vcproj
boincmgr.vcproj
../boinc_depends_win_vs2005
<Various Files>
svn path=/trunk/boinc/; revision=19672
<ignore_cuda_dev>n</ignore_cuda_dev>
<ignore_ati_dev>n</ignore_ati_dev>
to ignore (not use) specific NVIDIA or ATI GPUs.
You can ignore more than one.
svn path=/trunk/boinc/; revision=19566
Rom Walton