| Author |
Message |
|---|
MarkJ  Volunteer moderator
Volunteer tester
Send message
Joined: 24 Dec 08
Posts: 738
Credit: 200,909,904
RAC: 0
Level
Scientific publications
      |
|
Another new one. Currently only for Windows. Report any problems you get with it to the Alpha email list. This list needs registration.
The un-official change log starting with 6.10.12...
Rom 2 October 2009
- client: fix crashing bug introduced in [18605]
Rom 5 october 2009
- client: if downloaded project list file is garbage, ignore it.
- all: accept <foo /> as an XML bool
- client: Apparently it is valid for the autoproxy to return successful API completeion but a null proxy list. Check for the null instead of crashing.
- client: only support one of the ati13* plan classes at a time. A couple users had not updated their amdcal* runtime libraries after upgrading catalyst drivers. This was leading to crashes of the project applications when work was supplied looking for the old DLL names.
- client: fix a handle leak I just introduced (From: Andreas a.k.a Gipsel)
- lib: Fix memory/resource leak. (From Nicolás Alvarez)
- lib: Add additional ATI descriptions.
- lib: Fix some inaccurate ATI capabilities in certain cards. (From: Andreas a.k.a Gipsel)
- lib: Fix memory/resource leak. (From Nicolás Alvarez) (reprise)
- client: restore calDeviceGetInfo(), add its info to COPROC_ATI struct (some plan class might need to know this).
- Code cleanup.
- client: better behavior if a GPU goes away:
1) if an APP_VERSION is missing a coprocessor, don't delete it and its files. (If the coprocessor returns, we won't need to re-download)
2) if a RESULT uses an app version that is missing a coprocessor, abort it (rather than deleting it). The client will report the result on the next scheduler RPC, and the server will make a new instance.
- client: fix bug where if you change project "no CPU/NVIDIA/ATI" prefs and update, the change wouldn't take effect until client restart.
- client: fix bug in enforcement of "no CPU/NVIDIA/ATI" prefs
- client: make the order of the result vector consistent with the order used to select coproc jobs
- client: improve coproc_debug messages
- client: if a task is running, uses a GPU, and the system has >1 GPU, append text to its resource string saying which GPU it's using
- manager: tweak Task properties text
- DIAG: Suspend threads right before extracting their context and then resume them afterwards. Otherwise we could end up in a deadlock state where both the main thread and a support thread are attempting to use the same system resource. In the last situation it was way down in Winsock.
- DIAG: Don't resume after the thread has been suspended, otherwise the thread stack may be trashed after extracting the context. This should still be okay though as by the time the diagnostics framework has gotten here it has already downloaded all the symbols it'll need.
And 6.10.13...
Rom 5 october 2009
- client: Fix crash that was introduced 7 months ago. (From Nicolás Alvarez)
- client: Fix a missed checkin that prevents a crash during autoproxy detection.
____________
BOINC blog |
|
|
|
|
|
One feature we had asked for last year finally got in and it now shows the GPU on which the task should be running if there is more than one GPU in the system. Note that this may not be the GPU on which the task is actually running, but the one BOINC thinks it is running.
The reason I bring this up and make this distinction is that I was running into problems with my two HD4870 cards when they were running one MW and one Collatz task at the same time. Run times went up a lot... they stayed up even though 6.10.13 said they were running on different GPUs ...
It looks like an error in one or both of the applications and that version 2.05 Collatz and 20b MW will fix this issue if nothing else ... I had several good runs with those two application versions.
Most of the other issues are "minor" in that if you have not seen regular crashes to this point the crash fixes won't help you any.
The other major change is still not a good one though I still have hopes they will get it right eventually. And that is if you have a minor hiccup with drivers or a card crash that BOINC will not delete your GPU work as it does now. Sadly the current version now only marks all tasks aborted ... which is not an improvement. We asked for them to just let it ride so that when the drivers recover we can move on ...
{edit}
Oh, and the task list is supposed to sort in the order that the tasks will run ... does not seem to work right for me ... though I asked Richard H. to look at it as he was the originator ... |
|
|
|
|
|
If you're a BOINC alpha tester, some things I'd suggest testing:
1. Whether it corrrectly reports situations where a workunit is actually using more than one GPU at the same time.
2. Whether any screensaver included with it can handle situations where it is displaying graphics from a workunit for which the graphics fills the entire screen and it decides it's time to move the graphics elsewhere on the screen.
Especially when it's displaying graphics on a 9800 GT, a GPU that's also running a GPUGRID workunit, or both.
3. If enough workunits go into high priority mode that not all of them are expected to complete by their deadlines without ignoring any limits on how much memory BOINC is allowed to use, does that version still require those high priority workunits to obey any restrictions on how much memory BOINC is allowed to use? If not, some future version may need a new memory limit setting specific to that situation. I believe that The Lattice Project currently has some CPU workunits with such high memory requirements that they are suitable for testing that on machines with multiple CPU cores, but with the memory limit set too low to allow running The Lattice Project workunits on each of them while still meeting the limit. |
|
|
|
|
|
The other significant change in v6.10.13 is that it should respect requests not to use the CPU or GPU at individual projects (i.e. not request work for inappropriate resources). The server code has been updated here (use the new controls at the top of GPUGRID preferences), and also at AQUA for those who want to test it the other way round. |
|
|
|
|
|
Collatz and SaH (I am pretty sure) are also running the new Server Side software. |
|
|
|
|
Collatz and SaH (I am pretty sure) are also running the new Server Side software.
SaH put in the update to show task run time/application just before their big crash, but they didn't put in the new CPU/GPU code. AQUA was in the same state until I asked them to do a second update last night.
You can tell from the preferences page source:
AQUA and here: <!-- $Id: user.inc 19201 2009-09-28 16:19:20Z davea $ -->
SaH: <!-- $Id: user.inc 18352 2009-06-10 18:34:51Z davea $ -->
or, more trivially, the new controls have separate checkboxes for NVIDIA and ATI GPUs: the old version (still visible here) just says 'Use GPU if available'. |
|
|
|
|
Collatz and SaH (I am pretty sure) are also running the new Server Side software.
SaH put in the update to show task run time/application just before their big crash, but they didn't put in the new CPU/GPU code. AQUA was in the same state until I asked them to do a second update last night.
You can tell from the preferences page source:
AQUA and here: <!-- $Id: user.inc 19201 2009-09-28 16:19:20Z davea $ -->
SaH: <!-- $Id: user.inc 18352 2009-06-10 18:34:51Z davea $ -->
or, more trivially, the new controls have separate checkboxes for NVIDIA and ATI GPUs: the old version (still visible here) just says 'Use GPU if available'.
Color me corrected... :) |
|
|
MarkJ Volunteer moderator
Volunteer tester
Send message
Joined: 24 Dec 08
Posts: 738
Credit: 200,909,904
RAC: 0
Level
Scientific publications
|
|
Now superceeded by 6.10.14. See seperate message thread for details.
____________
BOINC blog |
|
|
/ 
Reply
Quote
Paul D. Buck
