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
David Anderson