New boinc client 7.0.25

[wayliff]

Anyone tried the new recommended boinc client? If so, any feedback\comments\issues?

http://boinc.berkeley.edu/download_all.php
Version 7.0.25

I have plans to install on two machines once all current WUs are complete.

************************************
Complementing using release notes link from blackgrffn.

Summary of New features
* Localized and accessible Simple GUI
* OpenCL Support
* Improved Virtual Machine Support
* REC-Based scheduler

Scheduler Changes
The new scheduler observes the resource share setting better than the old scheduler.
Another change is the client will no longer attempt to get work right after completing a job. Instead it will wait until it drops below a threshold and then start asking around for work. You can change both the lower threshold and upper threshold by changing these preference settings:

* 'Maintain enough tasks to keep busy for at least' (lower threshold)
* '... and up to an additional' (upper threshold)

 

[blckgrffn]

Sweet - looks like I won't have to use a beta client for POEM@Home GPU crunching after all?

Any major changes/fixes? I'll try it today...

http://boinc.berkeley.edu/wiki/Release_Notes

"To clarify, when you upgrade to BOINC 7.0.25 or later, everything should work as normal; work in progress will continue to run. When you downgrade from 7.0.25 or later to an earlier 6.x.x version, work in progress will disappear. You'll still be attached to all your projects. The client will fetch work from them, only if the project has 'resend lost work' on, will it be reissuing the previous lost work, which will start from the beginning."

OpenCL support is listed as a major feature for this release.

I just ran the 7.025 client install while BOINC was running, took about 20 seconds, everything picked itself up flawlessly. Very impressive.

One GUI element I noticed is an "exclusive application" tab in computing preferences. Looks like you can tell BOINC to suspend when you launch, BF3.exe, for example. I think that's pretty slick...

 

[zzuupp]

Due to changes to BOINC on how client_state.xml is written to, once you have gone over to 7.0, you cannot return to 6 without getting problems.

I'm going to hold off a bit.

 

[Sunny129]

while i haven't yet tried the official v7.0.25 release, i did try w/ a few different beta versions (6.13.xx, 7.0.15, 7.0.18, and 7.0.24)...and i had issues w/ work fetch and maintaining a cache...

...granted, the work buffer settings have changed - in v6.12.xx, we had the "connect about every x.xx days" and the "additional work buffer" fields under the network usage tab in the computing preferences...w/ v6.13.xx or later (including all 7.0.xx versions), we now have the "minimum work buffer" and the "additional work buffer" fields. it was explained to me on the MW@H forums that when migrating to v6.13.xx or later, you should not change the "minimum work buffer" value, and that the value that was being used for the "connect about every x.xx days" field previously in v6.12.xx should be applied to the "additional work buffer" field on the newer BOINC version.

nevertheless, no matter how i fiddled w/ these values, i could not maintain a project cache for either MW@H or SETI@H...that is to say, regardless of the fact that my host was able to download multiple tasks at a time (depending on my work buffer settings), my host would stop downloading new work until the caches for either project, MW@H or SETI@H, were reduced to zero. at that point it would download more work, but again wouldn't maintain the cache. to me that defeats the entire purpose of having and maintaining a cache/work buffer.

now i didn't see others with the same problem on the MW@H forums, so it may unique to my host (or perhaps only a handful of hosts around the planet). but if anyone has issues like this regarding fork fetch and maintaining a cache w/ v7.0.25, please share it here...

 

[wayliff]

I am going to give it a spin on two machines soon. If I notice something out of the ordinary, in a bad way, I'll post that info.

 

[Rattledagger]

All computers has been on v7 for some time, but haven't upgraded all to v7.0.25 yet.

Now, the big change is cache-settings, there the old "Connected..." is now called "Minimum cache size", while "Additional..." works more or less like before.

If example "Minimum..." is set to 3 days and "Additional..." is set to two days, the client should ask for work then drops below 3 days cached, and will fill upto max 5 days with work. But, while older clients kept re-asking until "Additional..." was also fulfilled, v7 will only ask for work then dropping below the "Minimum..." so with my example the cache-size will possibly never be over 4 days total or something... If a scheduler-request anyway is sent-off, it can also include a work-request even if above "Minimum..."-size.

With WCG I've not had any problems keeping the desired cache-size, and did also fill-up with SIMAP-work as it should until work-supply ran-out again.

Sunny129, going by the description it can look like you've mixed-up the settings, or possibly atleast then it comes to SETI@home there can be many other reasons for not keeping the cache full. Not sure with Milkyway...

 

[Sunny129]

Sunny129, going by the description it can look like you've mixed-up the settings, or possibly atleast then it comes to SETI@home there can be many other reasons for not keeping the cache full. Not sure with Milkyway...

i don't know man...my description is identical to yours - "additional work buffer" remains the same as before, and "minimum work buffer" is the new "connect about every x.xx days." it doesn't really matter, as i tried swapping values also, and that didn't solve the problem either...

regardless, as now isn't a good time for me to update anyways. i'll be sticking w/ BOINC v6.12.43 until the SETI gauntlet has finished.

 

[somethingsketchy]

So far my only complaint is the client seems to be wasteful of screen space underneath the "Tasks" portion of the client interface. I'm not sure if the blank space is for graphics (a la SETI graphs from the classic days), but right now it's a bit wasteful GUI-wise.

 

[wayliff]

i don't know man...my description is identical to yours - "additional work buffer" remains the same as before, and "minimum work buffer" is the new "connect about every x.xx days." it doesn't really matter, as i tried swapping values also, and that didn't solve the problem either...

regardless, as now isn't a good time for me to update anyways. i'll be sticking w/ BOINC v6.12.43 until the SETI gauntlet has finished.

I have been using the client for a couple of days now and the thing I noticed is that the "minimum work buffer" does not seem to work like before "connect every x days". I had that set to 0.1 but every time I check I have way too many WUs sitting and waiting to be reported which at that point I manually report them.

I've changed it to 0.5 and thinkin that perhaps the higher the number then the more often it will connect as it would want to maintain that higher minimum buffer. Will report back and see if something will be different.

 

[Sunny129]

I have been using the client for a couple of days now and the thing I noticed is that the "minimum work buffer" does not seem to work like before "connect every x days". I had that set to 0.1 but every time I check I have way too many WUs sitting and waiting to be reported which at that point I manually report them.

I've changed it to 0.5 and thinkin that perhaps the higher the number then the more often it will connect as it would want to maintain that higher minimum buffer. Will report back and see if something will be different.

thanks for keeping an eye on it. i just got my 2nd cruncher back up and running after being down for 2 weeks due to a nasty virus i couldn't kick, and i don't really want to play around w/ a new BOINC version right before the SETI Gauntlet starts...

 

[Rattledagger]

I have been using the client for a couple of days now and the thing I noticed is that the "minimum work buffer" does not seem to work like before "connect every x days". I had that set to 0.1 but every time I check I have way too many WUs sitting and waiting to be reported which at that point I manually report them.

I've changed it to 0.5 and thinkin that perhaps the higher the number then the more often it will connect as it would want to maintain that higher minimum buffer. Will report back and see if something will be different.

You didn't say that your "additional..." buffer is...

But, let's say your "additional..." is 1 day.

If so, the behaviour is as intended, since with "minimum..." at 0.1 you'll cache upto 1.1 days of work (most likely less) and only ask for more work then drops below 0.1 days.

BTW, one of the reasons for the change in cache-behaviour is to cut-down on how often client does scheduler-request, so having many results waiting to report is as intended. If there's no reason to ask for more work, client will still at the latest report a result 24 hours after the result-files for it was uploaded, or if it's less than 24 hours until deadline and some other rules. For users that has configured time-of-day to allow network-connection, the client should report results if less than 30 minutes until disconnection (I've not tested if this latest behaviour works as it should).

 

[salvorhardin]

I have been using the beta versions since 7.0.3. With 7.0.17 they tweaked the work fetch policy that whenever boinc communicates with the server for anything other than fetching work to fill up the queue. To get boinc to consistently keep my queue at max I added <report_results_immediately>1</report_results_immediately> to my cc_config.xml file. Whenever I complete a result if i'm below my max it will request work. It worked perfectly for me when I ran poem on my 5850, but when I switched to my 4830 with a different boinc instance I couldn't keep a queue larger than 3 wus. It worked fine on moowrapper and milkyway (kept the limit).

Edit: was checking the boinc forums and found out that the report results command is now ignored by the client.

 

[wayliff]

You didn't say that your "additional..." buffer is...

But, let's say your "additional..." is 1 day.

If so, the behaviour is as intended, since with "minimum..." at 0.1 you'll cache upto 1.1 days of work (most likely less) and only ask for more work then drops below 0.1 days.

BTW, one of the reasons for the change in cache-behaviour is to cut-down on how often client does scheduler-request, so having many results waiting to report is as intended. If there's no reason to ask for more work, client will still at the latest report a result 24 hours after the result-files for it was uploaded, or if it's less than 24 hours until deadline and some other rules. For users that has configured time-of-day to allow network-connection, the client should report results if less than 30 minutes until disconnection (I've not tested if this latest behaviour works as it should).

yeah you got the additional buffer correct.
Agreed, I figured the changes were to cut down on client requests.