Welcome to MilkyWay@home

BOINC 6.10.14

Message boards : Number crunching : BOINC 6.10.14
Message board moderation

To post messages, you must log in.

AuthorMessage
Emanuel

Send message
Joined: 18 Nov 07
Posts: 280
Credit: 2,442,757
RAC: 0
Message 32446 - Posted: 16 Oct 2009, 21:33:33 UTC
Last modified: 16 Oct 2009, 21:35:33 UTC

For all you GPU users out there, version 6.10.14 was just posted for Windows. Somewhat sanitized changelog as follows: (sorry about the dots, had to work around the broken code tags)

- MGR: Fix the Statistics page Save/Restore project display feature.
- MGR: If aborting multiple tasks, ask "Are you sure?" only once.
- client: Fix crash that was introduced 7 months ago. (From Nicolás Alvarez)
- client: remove redundant 0s in job log
- scheduler: skip deadline check for non-CPU-intensive projects
- client: add --unsigned_apps_ok cmdline option and <unsigned_apps_ok> config 
. . . . . option. This tells the client to allow unsigned apps. For testing.
. . . . . No file xfers or other network traffic will be allowed if set.
- client: add <exit_after_finish> option (same as cmdline flag)
- client: add <skip_cpu_benchmarks> option (same as cmdline flag)
- client: print message if abort past-deadline unstarted job
- client: improve message when have NVIDIA drivers but no GPU
- client: if anonymous platform description (app_info.xml) doesn't specify 
. . . . . FLOPS for a GPU app, assume that it runs at CPU peak speed rather 
. . . . . than GPU peak speed. Better to be conservative, otherwise job might 
. . . . . be aborted due to time limit exceeded.
- client: on startup, if a coproc needed by a job is missing, set a 
. . . . . "coproc_missing" flag rather than aborting the job. If use removes 
. . . . . a GPU board while there's a large queue of GPU jobs, they'll stay
. . . . . queued (until their deadline passes).
. . . . . Note: this doesn't fix the situation where user connects via Remote
. . . . . Desktop while GPU jobs are running or queued. We should check for
. . . . . Remote Desktop every minute or so, and stop GPU jobs.
- client: the get_all_projects_list() RPC doesn't require auth
- client: don't multiply checkpoint interval (i.e., "disk interval" pref)
. . . . . by # processors.
- web: change description of pref to "Tasks checkpoint to disk at most 
. . . .every ..." and change it in the advanced prefs dialog too
- LIB: Make the is_remote_desktop compilable for all VS versions and SKUs.
- MGR: Fix initial first connection problem on startup.  I'm not sure why
. . . .it was only happening at startup, there might have been a few crashes
. . . .because of this issue as well.  The basic problem is that wxWidgets
. . . .had an exception handler around the initial frame creation and when
. . . .the first GUI RPC was issues to detect whether or not we were atached
. . . .to an account manager during menu creation the GUI thread would go
. . . .about doing idle processing while waiting for the GUI RPC thread to
. . . .initialize.  During this time the frame pointer is NULL and was getting
. . . .dereferenced which would halt window construction and stay there until
. . . .some other event was fired.
- MGR: Initial dose of code cleanup and shuffling.  Order the menu functions
. . . .in the order in which they are displayed in the menu.
- client: address the situation where GPUs become unusable for certain periods
. . . . . (e.g. when Remote Desktop is used on Win).
. . . . . - add is_usable() member function to COPROC.
. . . . . . . Currently this just calls the respective (CUDA or CAL)
. . . . . . . initialization function.
. . . . . . . We need to check whether this works and/or causes problems.
. . . . . - in enforce_schedule(), check whether usability has changed
. . . . . . for each GPU type.
. . . . . . If we've gone from usable to unusable, flag all jobs for that GPU
. . . . . . as coproc_missing (so they won't get run, and will quit if they're
. . . . . . running).
. . . . . . If we've gone from unusable to usable, clear the flag.
. . . . . . This should deal with all cases except where the client is started
. . . . . . up with GPUs unusable.
- client: bug fixes to the above. Don't fetch work for an unusable resource.
- update cal.h to current ATI code
- undo the above
- client/scheduler: standardize the FLOPS estimate between NVIDIA and ATI.
. . . . . . . . . . Make them both peak FLOPS, according to the formula
. . . . . . . . . . supplied by the manufacturer.
. . . . . . . . . . The impact on the client is minor:
. . . . . . . . . . - the startup message describing the GPU
. . . . . . . . . . - the weight of the resource type in computing long-term debt
. . . . . . . . . . On the server, I changed the example app_plan() function
. . . . . . . . . . to assume that app FLOPS is 20% of peak FLOPS
. . . . . . . . . . (that's about what it is for SETI@home)
- client: the weight of GPU debt in computing total debt should be
. . . . . (estimated throughput of all GPUs)/(estimated throughput of all CPUs)
. . . . . rather than the ratio of 1 GPU to 1 CPU.
. . . . . This change will hopefully cause ratios of granted credit
. . . . . to more closely match resource shares.
- client: multi-thread jobs were being given too high priority;
. . . . . in particular, they were preempting jobs in the middle of time slice.
. . . . . Solution:
. . . . . 1) don't use MT in the sort order defined by more_important().
. . . . . 2) add a 2nd reordering in which MT jobs are moved ahead
. . . . . . .of non-MT jobs, but only if #CPUs used is < #CPUs
. . . . . . .(see promote_multi_thread_jobs())
- client: the seqno of jobs in progress but not selected
. . . . . was being set to zero.  It should be runnable_jobs.size().
. . . . . This could potentially cause wrong scheduling decisions.
ID: 32446 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile GalaxyIce
Avatar

Send message
Joined: 6 Apr 08
Posts: 2018
Credit: 100,142,856
RAC: 0
Message 32447 - Posted: 16 Oct 2009, 21:39:11 UTC


Hmmmmmm. Not many changes then.

Thanks Emanuel ;)


ID: 32447 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Beyond
Avatar

Send message
Joined: 15 Jul 08
Posts: 383
Credit: 729,293,740
RAC: 0
Message 32467 - Posted: 17 Oct 2009, 2:34:29 UTC

Here's two:

One big change. This release finally fixes the 64bit start-up bug. I've tried it on 4 varying 64bit machines and on all of them v6.10.14 now correctly starts after a reboot. That's a big deal alone...

Also, when a GPU is not detected properly for whatever reason when BOINC starts, the GPU project WUs are now NOT unceremoniously dumped. Another important fix.
ID: 32467 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile arkayn
Avatar

Send message
Joined: 14 Feb 09
Posts: 999
Credit: 74,932,619
RAC: 0
Message 32471 - Posted: 17 Oct 2009, 3:40:31 UTC

MGR: If aborting multiple tasks, ask "Are you sure?" only once.


I like this one as well, I have on occasion had to abort quite a few units and it was nuts clicking yes for all of them.
ID: 32471 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile GalaxyIce
Avatar

Send message
Joined: 6 Apr 08
Posts: 2018
Credit: 100,142,856
RAC: 0
Message 32484 - Posted: 17 Oct 2009, 8:52:50 UTC

I'm not superstitious, but I'm glad to move away from version 13 ;p


ID: 32484 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
STE\/E

Send message
Joined: 29 Aug 07
Posts: 486
Credit: 576,548,171
RAC: 0
Message 32489 - Posted: 17 Oct 2009, 10:20:26 UTC - in response to Message 32471.  

MGR: If aborting multiple tasks, ask "Are you sure?" only once.


I like this one as well, I have on occasion had to abort quite a few units and it was nuts clicking yes for all of them.


All you have to do is Highlight all the Wu's you want to Abort & then when the Pop Up Box appears asking you Yes/No just Press & hold the Enter Key until all the selected Wu's are Aborted. Suspend all work first & it only takes a few seconds that way.

A option to Abort All would be nice though but that's the work around I've used on many occasion to Abort multiple Wu's ...
ID: 32489 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Bill592
Avatar

Send message
Joined: 19 May 09
Posts: 30
Credit: 1,062,540
RAC: 0
Message 32503 - Posted: 17 Oct 2009, 20:36:17 UTC

ID: 32503 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
bobgoblin

Send message
Joined: 8 Dec 07
Posts: 60
Credit: 67,028,931
RAC: 0
Message 32528 - Posted: 18 Oct 2009, 13:34:23 UTC - in response to Message 32489.  

MGR: If aborting multiple tasks, ask "Are you sure?" only once.


I like this one as well, I have on occasion had to abort quite a few units and it was nuts clicking yes for all of them.


All you have to do is Highlight all the Wu's you want to Abort & then when the Pop Up Box appears asking you Yes/No just Press & hold the Enter Key until all the selected Wu's are Aborted. Suspend all work first & it only takes a few seconds that way.

A option to Abort All would be nice though but that's the work around I've used on many occasion to Abort multiple Wu's ...



but holding down the enter key like that, i've had issues with the ones already aborted report then boinc accidentally deletes wu's i didn't want to abort.

I guess a Reset Project would be Abort All
ID: 32528 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Emanuel

Send message
Joined: 18 Nov 07
Posts: 280
Credit: 2,442,757
RAC: 0
Message 32570 - Posted: 20 Oct 2009, 9:45:28 UTC

6.10.15 is out for Windows. Doesn't really warrant its own topic as the only change seems to be an important fix for remote desktop users whose hosts are also contributing GPU resources, a combination I expect is pretty rare.
- client: Use is_remote_desktop() instead of the various GPU functions
. . . . . to determine when the client software has been switched into Remote
. . . . . Desktop mode and shutsdown GPU apps.  This will prevent App crashes.
ID: 32570 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile mikey
Avatar

Send message
Joined: 8 May 09
Posts: 3339
Credit: 524,010,781
RAC: 0
Message 32572 - Posted: 20 Oct 2009, 11:09:02 UTC - in response to Message 32570.  

6.10.15 is out for Windows. Doesn't really warrant its own topic as the only change seems to be an important fix for remote desktop users whose hosts are also contributing GPU resources, a combination I expect is pretty rare.
- client: Use is_remote_desktop() instead of the various GPU functions
. . . . . to determine when the client software has been switched into Remote
. . . . . Desktop mode and shutsdown GPU apps.  This will prevent App crashes.


Yeah I use RAdmin and it does not seem to have any effect on the remote pc at all. Now I use RAdmin thru my local network only, not over the WWW.
ID: 32572 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
MarkJ

Send message
Joined: 4 Oct 09
Posts: 12
Credit: 5,865,193
RAC: 0
Message 32574 - Posted: 20 Oct 2009, 11:31:50 UTC - in response to Message 32570.  

6.10.15 is out for Windows. Doesn't really warrant its own topic as the only change seems to be an important fix for remote desktop users whose hosts are also contributing GPU resources, a combination I expect is pretty rare.
- client: Use is_remote_desktop() instead of the various GPU functions
. . . . . to determine when the client software has been switched into Remote
. . . . . Desktop mode and shutsdown GPU apps.  This will prevent App crashes.


Well there is a little bit more to it. From the BOINC forum...

Rom Walton wrote:
Howdy Folks,

Major fixes for this release are:

1. Startup problems on reboot should be fixed. Everybody should reboot at least once and verify that the manager can start the client at logon.

2. The introduction of a limbo state when the GPU disappears. Task instances should error out if they go past deadline.

3. We introduced some code to detect Remote Desktop and to move GPU jobs into limbo until the user signs back into the console. The original detection code is where the .13 client was crashing, the new code doesn't appear to work correctly. If I can figure out what is going wrong I'll do another release for that.

Please give items 1 and 2 a few tries. Changing driver versions and that should trigger #2.


Charlie 16 October 2009
- MGR: Fix build break on Mac

Rom 19 October 2009
- client: Use is_remote_desktop() instead of the various GPU functions to determine when the client software has been switched into Remote Desktop mode and shutsdown GPU apps. This will prevent App crashes.

BOINC blog
ID: 32574 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Emanuel

Send message
Joined: 18 Nov 07
Posts: 280
Credit: 2,442,757
RAC: 0
Message 32583 - Posted: 20 Oct 2009, 18:36:07 UTC
Last modified: 20 Oct 2009, 18:42:35 UTC

Nah, all that stuff was for 6.10.14. The Mac build break only would have affected, you guessed it, Mac OSX builds :P (which couldn't be posted until the build break was fixed, by definition)

We've had another small update, by the way, bumping the version to 6.10.16.
Changelog:
- client: Use the ANSI version of WTSQuerySessionInformation to determine if Remote Desktop is in use.
ID: 32583 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Chris S
Avatar

Send message
Joined: 20 Sep 08
Posts: 1391
Credit: 203,563,566
RAC: 0
Message 32589 - Posted: 20 Oct 2009, 22:26:02 UTC

6.10.16 20 Oct
6.10.15 19 Oct
6.10.14 16 Oct
6.10.13 5 Oct
6.10.12.5 Oct
6.10.11 29 Sept
6.10.10 28 Sept
6.10.9 25 Sept
6.10.8.25 sept
6.10.7 23 Sept
6.10.6 18 sept

Any bets on 6.10.99 by Xmas?
ID: 32589 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Bill592
Avatar

Send message
Joined: 19 May 09
Posts: 30
Credit: 1,062,540
RAC: 0
Message 32596 - Posted: 21 Oct 2009, 4:24:08 UTC - in response to Message 32589.  

6.10.16 20 Oct
6.10.15 19 Oct
6.10.14 16 Oct
6.10.13 5 Oct
6.10.12.5 Oct
6.10.11 29 Sept
6.10.10 28 Sept
6.10.9 25 Sept
6.10.8.25 sept
6.10.7 23 Sept
6.10.6 18 sept

Any bets on 6.10.99 by Xmas?



I’m holding out for ver. 7.40.14

I predict this will be a stable version

and, will be out in February.


Bill

ID: 32596 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile verstapp
Avatar

Send message
Joined: 26 Jan 09
Posts: 589
Credit: 497,834,261
RAC: 0
Message 32602 - Posted: 21 Oct 2009, 10:42:30 UTC

At the current rate I predict 7.40.14 by xmas, and still not stable. :D
Cheers,

PeterV

.
ID: 32602 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Nick

Send message
Joined: 21 Oct 09
Posts: 6
Credit: 20,040
RAC: 0
Message 32610 - Posted: 21 Oct 2009, 17:11:13 UTC

Hei!

Is this version stable with Vista Home Basic? I've heard that .13 is better for Vista users...

Cheers
ID: 32610 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote

Message boards : Number crunching : BOINC 6.10.14

©2024 Astroinformatics Group