boinc/todo

229 lines
7.2 KiB
Plaintext
Raw Normal View History

est_time_to_completion doesn't work for non-running tasks
get timezone working on all platforms
get benchmark working as separate process
must do this before send first scheduler request
Windows hostinfo: memory, cache, swap
validate in crontab
email account ID
formatting of team, top user page
top hosts page is screwed up
make "external user view" page (no private info)
list hosts 1 per line, linked
Windows client
"bring up graphics" button/menu item in core client
make mini-logo
test uninstall
fix "unable to calculate"
fix disk usage labels, limit size of pie
print GB/MB/KB correctly for usage chart
get rid of xfers, results eventually
messages: prepend project name, include date and time
xfers: show file size,
completed xfers: show elapsed time
completed results: show final CPU time
-----------------------
test feeder reread-DB mechanism
use PHP session mechanism instead of our own cookies
use https for login (don't sent account ID or password in clear)
protect project admin web pages (htaccess)
Deadline mechanism for results
- use in result dispatching
- use in file uploading (decide what to upload next)
- use in deciding when to make scheduler RPC (done already?)
create "result adder" program that detects WUs that don't have
a canonical result yet, and should,
and creates more results for them.
This should detect situations where we're getting lots
of error results, and skip over those WUs
CPU benchmarking
This should be done by a pseudo-application
rather than by the core client.
This would eliminate the GUI-starvation problem,
and would make it possible to have architecture-specific
benchmarking programs (e.g. for graphics coprocessor)
or project-specific programs.
Testing framework
better mechanisms to model server/client/communication failure
better mechanisms to simulate large load
do client/server on separate hosts?
Add "garbage-collect state" fields to WU, result
whether deletion of files is OK, is done
investigate binary diff mechanism for updating persistent files
verify support for > 4 GB files everywhere
use FTP instead of HTTP for file xfer??
measure speed diff
Delete files if needed to honor disk usage constraint
inform user if this happens
implement max bytes/sec network preferences
Local scheduling
more intelligent decision about when/what to work on
- monitor VM situation, run small-footprint programs
even if user active
- monitor network usage, do net xfers if network idle
even if user active
The following would require client to accept connections:
- clients can act as proxy scheduling server
- exiting client can pass work to another client
- client can transfer files to other clients
User/host "reputation"
keep track of % results bad, %results claimed > 2x granted credit
both per-host and per-user.
Make these visible to project, to that user (only)
Storage validation
periodic rehash of persistent files;
compare results between hosts
Include account ID in URL for file xfers
This would let you verify network xfers by scanning web logs
(could use that to give credit for xfers)
Global preferences
implement disk usage prefs
time-of-day prefs?
test propagation mechanism
set up multi-project, multi-host test;
change global prefs at one web site,
make sure they propagate to all hosts
limit on frequency of disk writes?
max net traffic per day?
implement in client
Per-project preferences
test project-specific prefs
make example web edit pages
make app that uses them
set up a test with multiple projects
test "add project" feature, GUI and cmdline
test resource share mechanism
Proxies
work through HTTP, Socks proxies
look at other open-source code (Mozilla?)
Documentation
simplify/finish docs on server installation
get rid of text in INSTALL and INSTALL_CLIENT;
they should just refer to .html files
Testing in general
figure out how to set up multi-project, multi-host tests
from a single script
automate some simple test cases
Messages from core client
decide what messages should be shown to user, and how
log file? GUI? dialog?
CPU benchmarking
review CPU benchmarks - do they do what we want?
what to do when tests show hardware problem?
How should we weight factors for credit?
run CPU tests unobtrusively, periodically
check that on/conn/active fracs are maintainted correctly
check that bandwidth is measured correctly
measure disk/mem size on all platforms
get timezone to work
batteries on windows
WU/result sequence mechanism
design/implement/document
Multiple application files
document, test
CPU accounting in the presence of checkpoint/restart
test
Test nslots > 1
Redundancy checking and validation
test the validation mechanism
make sure credit is granted correctly
make sure average, total credit maintained correctly for user, host
Scheduler RPC
formalize notion of "permanent failure" (e.g. can't download file)
report perm failures to scheduler, record in DB
make sure RPC backoff is done for any perm failure
(in general, should never make back-to-back RPCs to a project)
make sure that client eventually reloads master URL
Data transfer
make sure restart of downloads works
make sure restart of uploads works
test download/upload with multiple data servers
make sure it tries servers in succession,
does exponential backoff if all fail
review and document prioritization of transfers
review protocol; make sure error returns are possible and handled correctly
Application graphics
finish design, implementation, doc, testing
size, frame rate, whether to generate
Work generation
generation of upload signature is very slow
Windows GUI
finish design/implement
display credit info, team
Windows screensaver functionality
idle-only behavior without screensaver - test
Versioning
think through issues involved in:
compatibility of core client and scheduling server
compatibility of core client and data server
compatibility of core client and app version
compatibility of core client and client state file?
Need version numbers for protocols/interfaces?
What messages to show user? Project?
Scheduler
Should dispatch results based on deadline?
test that scheduler estimates WU completion time correctly
test that scheduler sends right amount of work
test that client estimates remaining work correctly,
requests correct # of seconds
test that hi/low water mark system works
test that scheduler sends only feasible WUs
Persistent files
test
design/implement test reporting, retrieval mechanisms
(do this using WU/results with null application?)
User HTML
leader boards
NET_XFER_SET
review logic; prevent one stream for starving others
test HTTP redirect mechanism for all types of ops
prevent file_xfer->req1 from overflowing. This problems seems to be
happening when the file_upload_handler returnes a message to the
client that is large. This causes project->parsefile to get wrong
input and so on.