BOINC 6.6.17 is out. As we usually state in these message threads is should be noted that this is a Development version and may not work correctly.

The unofficial change log is here

---

BOINC blog

*** WARNING ***

In the course of testing BOINCs v6.6.14/15/16 for compatibility with optimised applications, Lunatics uncovered the cause of the unexpectedly high number of reports of EDF ('High Priority') running with CUDA/optimised applications. The bug in BOINC has been (at least partially) corrected in v6.6.17 - we're waiting for the build to test - and you should see less EDF from now on.

BUT: this early EDF is one of the reasons why large cache requests have very rarely been filled in the past. Once any SETI task (AP, MB, or CUDA) goes into High Priority, no further work will be requested.

Until now.

With BOINC v6.6.17, you are much more likely to get what you ask for. And that may be much more than you are expecting. Given our recent discussions about BOINC CPU usage with large caches, BOINC may even crash. Your computer may even crash.

In the early days of testing for BOINC v6.6.17, I strongly advise that you turn down your requested cache size, especially on fast multi-cpu, multi-gpu rigs, to no more than one or two days: then turn it back up gradually, allowing work fetch to complete between each change.

And then let us know how you got on!

BOINC Alpha reporting of problems

Don't just say which version of BOINC you run, but also on what operating system and add a detailed log of what your BOINC is doing.

Run with at least these flags on: <work_fetch_debug>, <sched_op_debug> and one run with <debt_debug> from the cc_config.xml file. Catch that log and post with it on the BOINC Alpha list.

Without it, the developers won't be able to be of any help, while you will probably only annoy them as they'll have to ask for the nth time that you add those flags and send them a new log.

---

running boinc 6.6.17
cuda 608

the elapsed time counts all the time instead of just when it uses cpu.

Is this new?
or is something wrong?

Elapsed time is wall-clock time. If you want to see the CPU time taken on the task, go to the Tasks tab, click on the task, click on Properties.

As far as I know it doesn't work on the GPU yet, or at least, BOINC isn't showing time taken by the GPU yet. Don't know if it ever will.

---

I could swear that the cuda tasks in the boinc manager tasks tab elapsed time column did not count time unless it was using the cpu.

how long has the properties button been there? I havent noticed it before.

-The BOINC FAQ Service
In this link provided by Ageless I found the answer, copied below.

In BOINC Manager it shows that the CPU time for a CUDA task is mere seconds, but the task runs for hours. Why is this?
BOINC does not follow GPU time yet. That's planned for a future version.
For now it will only count CPU time. For CUDA this means the time it takes the CPU to transfer the task from disk into the video RAM and when the task is done, transferring it back.
The GPU will do the whole calculating of the CUDA task.

the answer was near the bottom of the page.

thanks for the link.

how long has the properties button been there? I havent noticed it before.

Um, about 2 or 3 versions. I think since 6.6.13 or .14, but could be mistaken about that. The Elapsed time came in 6.6.16

---

Make sure you study that well. Now you told me you read it, you'll be getting a written test about it tomorrow. ;-)

---

I have added it to my favorites for easy access, I am sure that I will not remember all the information there.

Ok, now here's a strange one for you.

Yester day I upgraded my main machine from 6.6.16 to 6.6.17. I KNOW it upgraded.

Just a bit ago i received my replacement Nvidia 295 and got it installed. In the midst of messing with it, I was in Boinc Manager and noticed that the version number said 6.6.16! I was like, WTH?!?

I re-ran the 6.6.17 install again and it went fine, including the 30 seconds of hard hitting hard disk action like yesterday.

I dunno what the deal was but that was strange.

Rob

---

I was like, WTH?!?

I don't know either, but BOINC Manager isn't necessarily the place to check the version number. You can run BM 6.4.7 on a 6.6.16 client; BM will then show 6.4.7

When BOINC upgrades the client part, it will run benchmarks when first starting up. If you see that, including a message alike "19-Mar-09 11:58:12 Version change (6.6.15 -> 6.6.17)", you know you've done it correctly.

When you run BOINC first time after an upgrade and there's no benchmarks, it hasn't upgraded.

Or Find the boinc.exe in your BOINC directory, right-click on it, properties, version. That'll show the version number of the client.

---

Aha, we have a server crash. Presumably, no work sent for several successive fetch requests (unless you get lucky with a resend).

We get to test the hidden backoffs and the recovery cycle.

Aha, we have a server crash.

But Friday the 13th was last week! ;-)

You don't want to test back-offs. (looks at LHC, Pirates & Hydrogen still backing off 24 hours)

---

I was like, WTH?!?

Two places to look:

Manager Help|About... [shows 6.6.17 on my system]

Manager status bar (extreme bottom/right) [Connected to localhost (6.6.17) on my system]

You don't want to test back-offs.

I didn't say I wanted to test them. I said we're all going to test them, like it or not!

(NOT, in my case. I've already done the testing, and reported the results, using LHC).

Backoff already 4 hours 16 minutes. Einstein has started to get a work boost, even though LTD is at -157,000 (and, strangely, climbing upwards towards zero), although running at three times resource share).

Backoff already 4 hours 16 minutes. Einstein has started to get a work boost, even though LTD is at -157,000 (and, strangely, climbing upwards towards zero), although running at three times resource share).

If the back-offs were large enough, the weekly "recovery" after the Tuesday backups would be a lot shorter.

The back-offs exist so that the BOINC client does not launch a Distributed Denial of Service attack against the BOINC servers.

... and they've been "tested" many times. They should be bigger.

---

Backoff already 4 hours 16 minutes. Einstein has started to get a work boost, even though LTD is at -157,000 (and, strangely, climbing upwards towards zero), although running at three times resource share).

If the back-offs were large enough, the weekly "recovery" after the Tuesday backups would be a lot shorter.

The back-offs exist so that the BOINC client does not launch a Distributed Denial of Service attack against the BOINC servers.

... and they've been "tested" many times. They should be bigger.

Ned, I don't know if you subscribe to the BOINC_alpha bug reporting list.

My comment alluded to bug reports I've posted there, where I've noted that the new work-fetch backoff takes no account of the reason why work is unavailable at the moment requested.

I'm happy to accept your point that a graduated re-request for new work following a project outage - whether planned or accidental - would help to avoid server overload.

But the present (new) policy doesn't discriminate between a catastrophic failure and a deliberate rationing of scarce WUs: my three v6.6.14+ testbeds have not downloaded a single LHC task since installing v6.6.14 two weeks ago, although work has been available for other hosts. (see BOINCstats)

Although the new code is a move in the direction you are suggesting, the implementation has not been as thoughtful as one would wish.

I'm running "stock" Boinc 6.6.17-64bit on my lappy, no optimized application installed yet. I immediately noticed that it will keep the GPU fed with work units, it also labels the Enhanced 6.08 work units as "(cuda)". It appears to me the latest Boinc runs cuda applications and fetches cuda applications as you would expect, woot!

I noticed in the c:/program data/.../setiathome.berkeley.edu folder there is not an app_info.xml file. If a install Raistmer's Opt V10a Pack along with a appropriate cc_config.xml file (or none, i've read it isn't necessary with Boinc V6.6 and up) I end up running one more AP work unit then the number logical CPU's, rather then placing a 6.08 cuda work unit on the GPU.

So how can one use Raistmer's Opt V10a Pack and get it to behave the same as stock??? I think what is in the app_info file needs to be updated for the latest boinc.

what would keep me from renaming Raistmer's executables the same a the stock executable and copy the dll files? i really don't want to do that, they could easily be over written by Bionc.

(this has been cross posted on lunatic's forums in the GPU V10a thread.)

---